Название РК и UTM-метки - это важно❗️
Я раньше об этом не особо задумывалась, и еще работая в агентстве порой не понимала аналитиков и программистов, которые нас за эти метки отчитывали..😀
Но когда я занялась построением сквозной аналитики самостоятельно, до меня наконец дошло.. Во первых важна сама метка: она должна содержать очень много динамических параметров, простая по типу: utm_source, utm_medium, utm_campaign, utm_term, utm_content в этом случае не подойдет. Тем более, если все параметры вы еще и пропишете статически. Так как ваши данные просто будут склеиваться.
Вот пример моей метки, которая вышла
после добавления всех возможных параметров : utm_source=google&utm_medium=cpc&utm_campaign=klient_google_search_usluga&utm_term={keyword}&adposition={adposition}&placement={placement}&matchtype={matchtype}&network={network}&device={device}utm_content={creative}|cid|{campaignid}|gid|{adgroupid}|kwid|{targetid}
Для каждой системы динамические параметры могут немного различаться, это нужно смотреть в документации. Так вот, свои метки мне пришлось менять около 5 раз. То они сразу были без динамики, то слишком мало, то я просто забыла разделитель поставить и все склеилось.
В чем то собственно суть проблемы?А в том, что все эти данные надо объединять по какому-либо ключу, и чтобы добиться истинной детализации необходимо, чтобы параметры различали строки.
А потом все это нужно склеить еще и с рекламными расходами, кликами и показами.
За 1,5 недели мной было написано около 100+ SQL запросов по вытягиванию и объединению тех или иных данных, их подсчету и агрегации. 100+ потому что были и ошибки, на каких-то микрозадачах я застревала. Сейчас сделано тоже не все🥲 Потому что вроде все ок, а потом оказывается, что я не так посчитала суммы и расход у нас мильен денег😅.
Я решила строить сквозную аналитику не на базе готовых решений, а
на базе данных Google BigQuery (Что зря что ли его изучала на курсе). И первая задача была - это залить все данные туда таким способом, чтобы еще они и обновлялись постоянно. С этой задачей я справилась почти не используя платных коннекторов.
Слова LEFT JOIN, RIHGT JOIN, FULL JOUIN, CROSS JOIN и др. иногда мне снятся в кошмарах😁 (Это способы объединения таблиц, не буду объяснять суть, но можете погуглить).
Меня некому проверить, потому что эту работу я провожу сама, есть косяки и костыли (костыль кстати теперь мое любимое слово😀).
Но когда я столкнулась с проблемой меток и названий рк, пошла быстренько в очередной раз все менять, то решила написать этот пост и поделиться тем, что название рк и и метка имеют действительно немаловажное значение.
Для примера, вот часть таблиц, которые мне пришлось сформировать - тут данные по ga4 +
g.ads + yandex direct -
https://prnt.sc/ryD1faJXxKwo. А вот как выглядит один из запросов -
https://prnt.sc/gs890eqIrZ-5. Запросы на ошибки и иногда их логику я пишу с ChatGPT, иногда беру некоторые вещи из курса. GPT действительно помогает их правильно исправить, а когда GPT заходит в тупик, я разбираю каждое написанное им слово и пытаюсь понять логику. Так как я не спец в SQL, специально его не изучала, но методом проб и ошибок функции начинают заучиваться. Главное понять логику и схемы таблиц.
Ну и подытожим тем, что когда база (а именно - метки, названия рк) сформированы некорректно, времени на переписывания уходит больше, а после переписываний нужно еще подождать новые данные, чтобы это проверить. Поэтому, если вас гнобит аналитик на работе, это скорее всего не просто так😀 А я кажется урок усвоила и подумаю над внедрением таких меток клиентам, которым возможно рано или поздно понадобится такая аналитика.
Ставьте реакции, если было интересно и я возможно напишу еще какой-нибудь пост про косяки и сложности, с которыми мне пришлось столкнуться🫣😎
