[GA4] Структура облікового запису Analytics

Структуруйте ресурси Google Analytics 4 відповідно до потреб своєї компанії
Зміст

Вступ

Якщо ви використовуєте Universal Analytics, вам відомо, що таке представлення даних. За їх допомогою в цьому сервісі можна створювати різні набори даних, наприклад за географічними місцеположеннями, сферами діяльності тощо. У Google Analytics 4 створювати такі набори можна різними способами. Деталізація й те, як ви контролюєте доступ до даних, залежить від ваших потреб і версії Google Analytics (стандартної чи 360).

Незалежно від того, яка у вас компанія: невелика з одним веб-сайтом чи корпорація з кількома брендами й тисячами товарів, практичні поради з налаштування ресурсу GA4 допоможуть вам досягти успіху.

Якщо вас цікавить інформація про ресурси Google Analytics 4, перегляньте наведені нижче статті та відео.

Ключові поняття та визначення

  • Обліковий запис – це набір ресурсів, дані яких належать одній юридичній особі та регулюються специфічними для регіону умовами використання.
    Чи важливо, щоб дані з кожного регіону належали окремій юридичній особі в цьому регіоні?
    • Якщо так, створіть окремі облікові записи для кожного регіону.
    • Якщо ні, створіть один обліковий запис і вкажіть у налаштуваннях регіон, де розташовано центральний офіс вашої компанії.
  • Ресурс міститься в обліковому записі та включає дані для однієї бази користувачів. Якщо певні дані (про лінійку товарів, бренд, додаток) потрібно аналізувати разом, вони мають бути в одному ресурсі (для користувачів Google Analytics 360 це може бути первинний ресурс).
    Ви збираєте дані про одну логічну базу користувачів? Коли ви зв’язуватимете Analytics з іншими продуктами, чи відкриєте ви їм доступ до всього цього масиву даних?
    • Якщо так, створіть один ресурс.
    • Якщо ні, створіть окремий ресурс або підпорядкований ресурс для кожної логічної бази користувачів.
  • Потік даних міститься в ресурсі та є джерелом даних із додатка або веб-сайту. Радимо використовувати не більше ніж 3 потоки даних на ресурс: 1 потік веб-даних, щоб відстежувати шлях користувача на веб-сайті, і по 1 потоку даних додатка для iOS та Android.
    • Потік даних додатка: для кожної комбінації з платформи та назви пакета додатка можна створити один потік даних.
    • Потік веб-даних: зазвичай для відстеження шляху користувачів сайту достатньо одного потоку. Якщо цей шлях включає кілька доменів, то застосовуйте також міждоменне відстеження, щоб між даними про користувачів і сеанси не було розбіжностей.

Приклади структури облікового запису й ресурсу

Нижче наведено практичні поради й рекомендації для різних користувачів і прикладів використання. У деяких випадках ці поради можуть бути не застосовними або їх потрібно адаптувати.

Рекомендуємо налаштовувати один обліковий запис на компанію й один ресурс на бренд або підрозділ компанії (за умови, що бренди та підрозділи компанії є унікальними/окремими операційними підрозділами з власними співробітниками/групами аналітиків).

Приклад А

  • Материнська компанія A: 1 обліковий запис 
    • Бренд X (автомобілі): 1 ресурс
    • Бренд Y (товари для домашнього вжитку): 1 ресурс
    • Бренд Z (побутова електроніка): 1 ресурс

У цьому прикладі материнська компанія має один обліковий запис і три окремі ресурси, кожен із яких містить дані лише про відповідний бренд або компанію. 

Приклад B

  • Компанія B: 1 обліковий запис
    • Лінійка товарів D (страхування нерухомості): 1 ресурс
    • Лінійка товарів E (автострахування): такий самий ресурс, що й для D
    • Лінійка товарів F (страхування життя): такий самий ресурс, що й для D та E

У цьому прикладі дані про всі лінійки товарів надсилаються в один ресурс. Компанія може мати клієнтів, які регулярно використовують кілька товарів, або часто проводити кампанії зі збільшення суми покупки чи перехресних продажів для різних товарів, тому всі дані доцільно переглядати разом. В аналізі окремих лінійок товарів цей ресурс може бути первинним для підпорядкованих.  

Приклад C

  • Невелика компанія C (наприклад, "М’ясна імперія"): 1 обліковий запис
    • Усі товари (м’ясна нарізка, сендвічі, напої тощо): 1 ресурс

У цьому прикладі "М’ясна імперія" – невелика компанія, що не потребує кількох ресурсів. Вона не має різних лінійок товарів і аналізує всі сукупні дані щодо доставки онлайн-замовлень, оскільки клієнти часто купують кілька позицій. З цієї причини для всіх даних використовується один ресурс.

Потоки даних

Кожен первинний ресурс містить потоки даних із додатка та/або веб-сайту, що є джерелом вхідних даних. Потік даних – це просто веб-сайт або додаток, який надсилає дані в певний ресурс GA4.

Радимо використовувати:

  • 1 потік веб-даних на ресурс;
  • 1 потік даних iOS на ресурс;
  • 1 потік даних Android на ресурс.
Кожен потік даних додатка можна зв’язати лише з одним ресурсом GA4. Враховуйте це, вирішуючи, які потоки зв’язувати з ресурсом.
Потоки даних не є аналогами представлення даних у Universal Analytics, тому їх не можна використовувати для розділення даних. Якщо ви все ж спробуєте це зробити, функцію зв’язування користувачів у різних потоках даних буде для вас обмежено, оскільки кожен із потоків є окремим джерелом даних. Це може призвести до завищення даних, оскільки повторювані користувачі можуть не видалятися залежно від того, як ви використовуєте Google Signals або власний статус чи User-ID.

Інтеграція із Search Console

Ресурс GA4 можна зв’язати із Search Console. Завдяки цьому ви отримуватимете багато нових даних у Google Analytics, зокрема пошукових запитів зі звичайного Пошуку Google і параметрів для звітів, зокрема цільових сторінок.

Ви самі вибираєте ресурс, який потрібно зв’язати з ресурсом Search Console. Якщо ви використовуєте підпорядковані та зведені ресурси, потрібно вибрати ресурс для зв’язування: первинний, підпорядкований або зведений.

Налаштувати зв’язок між ресурсами Google Analytics 4 та Search Console можна швидко й легко на сторінці адміністратора GA4. Зверніть увагу, що для цього потрібно бути підтвердженим адміністратором сайту в ресурсі Search Console і мати права адміністратора в ресурсі Google Analytics 4.

Налаштування звітів

Завдяки ресурсам Google Analytics 4 ви отримуєте повний контроль над показом звітів, показниками й параметрами в них, а також графіками. Ви можете налаштувати колекцію звітів, які стосуються лише певної групи працівників, наприклад команди спеціалістів із маркетингу. Однак зверніть увагу, що ви не можете обмежити доступ до таких колекцій, тобто їх бачитимуть усі користувачі ресурсу. Завдяки цьому можна налаштувати GA4 так, щоб найдоречніші звіти відображалися першими або до них було легко отримати доступ і не переглядати непотрібні звіти.

Приклад колекції звітів для команди спеціалістів із маркетингу

Приклад колекції звітів "Команда з маркетингу"

Ви можете налаштовувати окремі звіти в кожній колекції. Наприклад, більшість звітів у форматі таблиці мають показник "Загальний дохід", який відображається в стандартній конфігурації звіту. Це дуже зручно, якщо ви займаєтеся електронною комерцією, надсилаєте дані про доходи й хочете, щоб ваші команди могли їх аналізувати. Однак якщо у вас немає даних про доходи для створення звітів у Google Analytics, у цьому стовпці відображатиметься значення "0,00 дол. США" для кожного рядка. Якщо цей показник неактуальний для вашої компанії, його можна вилучити, щоб у звітах не було зайвої інформації.

Звіт "Події" з показником "Загальний дохід"

Звіт "Події" з показником "Загальний дохід"

Інтерфейс "Редагування події" (щоб вилучити показник, натисніть значок X поруч із ним)

Інтерфейс "Редагування події": щоб вилучити, натисніть значок X поруч із показником

Застосуйте зміни та збережіть звіт без показника "Загальний дохід"

Подію збережено без показника "Загальний дохід"

Тепер цей звіт став ще зручнішим для компанії, яка не має даних про дохід у Google Analytics або не хоче їх показувати.

Чистота даних

Радимо не тільки фільтрувати звіти для включення або виключення певних даних, але й ретельно стежити за їх чистотою, зокрема вилучати трафік із внутрішніх IP-адрес і небажані перенаправлення, а також правильно налаштовувати міждоменне відстеження.

Як виключити трафік із внутрішніх IP-адрес

Вилучення з наборів даних трафіку з внутрішньої IP-адреси може стати важливим кроком у налаштуванні для багатьох компаній, які отримують великий обсяг трафіку від працівників на веб-сайтах (наприклад, спеціаліста служби підтримки, який під час роботи з клієнтом часто посилається на статті Довідкового центру з веб-сайту своєї компанії). Завдяки цьому працівники вашої компанії (внутрішні користувачі) не викривлятимуть дані аналітики у звітах про приклади використання зовнішніми клієнтами. Наразі в GA4 цей фільтр установлено за умовчанням.

Інтерфейс "Створити правило для зовнішнього трафіку"

Як вилучити небажані перенаправлення

Ще один аспект чистоти даних – виключення небажаного трафіку переходів. Завдяки цьому можна відмежувати дані про певні джерела переходів від робочих даних – зберегти подію, але проігнорувати напрямок переходу, щоб атрибуція трафіку не зазнавала змін. Тепер наведена нижче конфігурація діє в GA4 за умовчанням.

Інтерфейс "Створення списку виключених перенаправлень"

Як налаштувати міждоменне відстеження

Поширеною проблемою користувачів Google Analytics завжди був міждоменний трафік. Раніше для роботи з ним потрібно було налаштувати міждоменне відстеження за допомогою Менеджера тегів Google, стандарту TMS або жорсткого кодування на сайті. Це потребувало додаткових зусиль, які не завжди були в користувачів Google Analytics, і часто призводило до проблем із чистотою даних, зокрема показувались нові або завищені показниками кількості сеансів та перенаправлень із власних доменів. У Google Analytics 4 доменне відстеження можна легко налаштувати в інтерфейсі користувача й у такий спосіб "почистити" дані.

Інтерфейс "Налаштування доменів"

Трансформації даних

У Universal Analytics трансформації даних відбуваються в межах конфігурації фільтра (наприклад, примусове написання всіх значень для певного параметра, як-от utm_campaign, з малої літери). Тепер це можна робити під час створення й редагування подій у ресурсах Google Analytics 4.

Наприклад, ви виявили подію, яку надіслано в ресурс GA 4 двічі, але різними способами. Можливо, подія start_now, яка приводить до ключової дії на вашому веб-сайті, надсилається в Google Analytics 4 кількома способами (start_now і startNow), оскільки вона відображається в кількох місцях на вашому веб-сайті, розроблених різними командами, які використовували неоднакові методи кодування. Це поширена проблема, яка може впливати на якість даних, однак тепер ви можете усунути її, створюючи та змінюючи події в інтерфейсі користувача.

Інтерфейс "Подія"

Для цього в розділі "Конфігурація" ресурсу GA 4 натисніть Змінити подію.

Кнопка "Змінити подію" в розділі "Конфігурація"

Ви перейдете на цей екран, де зможете вказати зміни, які потрібно внести. У цьому випадку можна вибрати подію start_now, яку ви хочете залишити, і внести зміни в іншу, щоб обидві події збігалися. У прикладі нижче показано, що назву "startNow" буде замінено на "start_now". Надалі використовуватиметься уніфікована назва, і звіти будуть набагато зручнішими, оскільки для цієї подіїі відображатиметься один рядок.

Інтерфейс "Змінити подію"

Дозволи й ролі користувачів

У ресурсах Google Analytics 4 використовуються спрощені й удосконалені функції, до яких можна отримати доступ залежно від ролей і обмежень. Нижче описано стандартні ролі.

  • Адміністратор – користувач, який повністю керує обліковим записом.
  • Редактор – користувач, який має право змінювати всі дані й налаштування, але не може керувати користувачами.
  • Аналітик – користувач, який може створювати й змінювати спільні об’єкти, а також переглядати дані та конфігурації.
  • Користувач із правами перегляду – користувач, який може переглядати дані звітів і налаштування конфігурації.

Крім того, у ресурсах GA4 можна приховувати дані про витрати й дохід в інтерфейсі звітів, застосувавши роль з обмеженням "Без доступу до показників витрат" або "Без доступу до показників доходу". Завдяки цьому корисному доповненню до дозволів користувача можна захищати конфіденційні дані компанії й водночас надавати певним аудиторіям доступ до даних про сайти й поведінку користувачів.

Примітка щодо обмежень, пов’язаних із витратами та доходом. Фільтри показників не працюватимуть для аудиторій, які містять дані про доходи. Крім того, користувачі з цими обмеженнями все одно зможуть переглядати кількість подій покупок. Тому, якщо ви не хочете переглядати ці дані, радимо використовувати підпорядкований ресурс.

Інтерфейс "Прямі ролі й обмеження щодо даних"

Спеціальні функції Google Analytics 360: підпорядковані й зведені ресурси

Підпорядковані ресурси

Підпорядковані ресурси – це новий вид ресурсів Google Analytics 4, доступний для облікових записів Google Analytics 360. За їх допомогою можна створити підмножину даних у первинному ресурсі. Якщо ви використовуєте підпорядковані ресурси, представлення даних непотрібні. Наприклад, ви можете створити підпорядкований ресурс, який містить підмножину даних із первинного ресурсу, а також надати певним користувачам доступ лише до цього підпорядкованого ресурсу. Крім того, підпорядковані ресурси надають можливості для очищення даних, а також керування даними, користувачами й функціями, що значно підвищує ефективність використання GA4 для великих компаній і підприємств.

Ви можете створити підпорядкований ресурс на основі будь-якого первинного, але не зведеного. Підпорядковані ресурси зв’язані з первинним за типом "один-до-одного".

У підпорядкованих ресурсах із користувачів Google Analytics 360 стягується додаткова плата. Докладніше дивіться в розділі Можливості заощадити нижче.

Як керувати даними

Один із найбільших прикладів використання підпорядкованих ресурсів – керування даними, тобто можливість контролювати тим, які дані включатимуться в ресурс і вилучатимуться з нього. Завдяки підпорядкованим ресурсам можна фільтрувати дані для створення набору, потрібного для певної аудиторії або прикладу використання. Це дає змогу краще впорядковувати дані та спростити доступ до них для певних аудиторій.

З цією метою в Universal Analytics часто використовували представлення даних (наприклад, створювали представлення лише для трафіку з Північної Америки або для даних маркетингових веб-сайтів). Розділення цих наборів даних дає змогу кожній групі отримувати доступ до інформації швидше й простіше, навіть якби ці набори були виокремлені завдяки більшій кількості фільтрів у первинному ресурсі. Для таких типів прикладів використання в підпорядкованих ресурсах це можна зробити за допомогою фільтрів імпорту й експорту між первинним і підпорядкованим ресурсами.

Дані можна відфільтрувати в підпорядкований ресурс за допомогою будь-якої події або спеціального параметра, отриманого в первинному ресурсі.

Як керувати користувачами

Підпорядковані ресурси також використовуються, щоб керувати користувачами. Наприклад, уявімо, що ваша компанія має суворі правила, у яких зазначено, що певний регіон (наприклад, Північна Америка) може переглядати підмножину даних цього регіону, однак інший регіон (наприклад, Південна Америка) не повинен мати до них доступу. За допомогою підпорядкованих ресурсів можна обмежити доступ до даних кожного регіону в межах його ресурсу, щоб вони були недоступні для інших регіонів.

Така стратегія так само спрацювала б для компаній, яким потрібно зберігати свої дані окремо для власних потреб або розділяти дані для маркетингового сайту й продукту (якщо одна команда вашої компанії не має бачити дані іншої).

Якщо вам не потрібно обмежувати доступ до даних, а треба просто спрямувати якусь підмножину користувачів до певних наборів даних, радимо відповідним чином налаштувати звіти та їх колекції. Наприклад, можна створити колекцію звітів, спеціально розроблених для маркетингової команди, щоб працівникам було простіше переходити до потрібних даних. Ці функції дають змогу впорядковувати дані в зручному форматі для певних аудиторій без додаткових витрат.

Зведені ресурси

Зведений ресурс містить дані принаймні з двох ресурсів. Зведений ресурс може містити дані зі звичайних і підпорядкованих ресурсів, але не з інших зведених ресурсів. Такі ресурси дають краще уявлення про компанію за її продуктами, брендами або регіонами, оскільки збирають дані з кількох ресурсів в одному обліковому записі. Зведені ресурси в GA4 і UA підтримують схожі приклади використання.

Ці ресурси працюють майже так само, як інші. Кожний зведений ресурс має власну квоту на спеціальні параметри, спеціальні показники, властивості користувача тощо. Усі налаштування контролюються у зведеному ресурсі (вони не успадковують налаштування від первинних ресурсів) і залежать від потреб зведеного ресурсу та зведеної бази користувачів.

За зведені ресурси з користувачів Google Analytics 360 стягується додаткова плата. Докладніше дивіться в розділі Можливості заощадити нижче.

Можливості заощадити

Кожна подія, що надсилається в підпорядкований або зведений ресурс, обробляється знову. За це в обліковому записі Google Analytics 360 може стягуватися додаткова плата. Плата за кожне додаткове звернення до події стягується в розмірі половини вартості початкового звернення до події. Тож звернення кожного підпорядкованого або зведеного ресурсу коштує 0,5 від звернення до події.

Щоб краще розуміти, як налаштування можуть вплинути на платежі, використовуйте нову функцію "Попередній перегляд платежу", доступну для партнерів, які пройшли Сертифікацію з Analytics. Вона допоможе клієнтам краще розуміти потенційні витрати, пов’язані з GA4 360.

Приклади підпорядкованих і зведених ресурсів

Якщо ви ще раз переглянете деякі приклади на початку цього посібника, то побачите, які налаштування потрібно вказати для кожного з них.

Компанія з кількома додатковими сферами діяльності

  • Компанія B: 1 обліковий запис
    • Лінійка товарів D (страхування нерухомості): 1 ресурс
    • Лінійка товарів E (автострахування): такий самий ресурс, що й для D
    • Лінійка товарів F (страхування життя): такий самий ресурс, що й для D та E

У цьому прикладі компанія має 1 обліковий запис з 1 первинним ресурсом. Компанія має кілька сфер діяльності, для яких, можливо, потрібно аналізувати дані окремо, але при цьому товари доповнюють одне одного й часто виникає потреба проаналізувати кілька товарів разом. З огляду на це компанія вирішила надіслати всі дані про товари в один первинний ресурс. Однак командам, які працюють із певними товарами, потрібно аналізувати дані окремо. У зв’язку з великим обсягом трафіку в усьому ресурсі вони вирішили створити окремий підпорядкований ресурс для кожної сфери діяльності.

Схема первинного ресурсу з трьома підпорядкованими йому ресурсами

 

Материнська компанія з кількома брендами

  • Материнська компанія: 1 обліковий запис
    • Бренд X (автомобілі): 1 ресурс
    • Бренд Y (товари для домашнього вжитку): 1 ресурс
    • Бренд Z (побутова електроніка): 1 ресурс

У цьому прикладі материнська компанія має 1 обліковий запис із 3 первинними ресурсами (по одному для кожного бренду). Кожен бренд працює окремо й повинен аналізувати власні дані, тому має свій первинний ресурс. Однак материнська компанія хоче звести всі бренди в один ресурс, щоб чітко бачити загальну кількість користувачів, загальний дохід тощо. У цьому прикладі материнська компанія створить зведений ресурс з усіма 3 ресурсами бренду, які будуть джерелами для зведених даних. Так компанія зможе отримати цілісне уявлення про свою ефективність, а бренди й надалі не будуть пов’язаними.

Схема материнської компанії з трьома брендами

 

Розгляньмо цей приклад докладніше. Материнська компанія має програму лояльності, яка поширюється на всі її окремі бренди. Якщо користувач бере участь у цій програмі лояльності, то має унікальний ідентифікатор, який можна пов’язати з ним як властивість користувача та/або параметр для кожної події.

Команда з питань винагород працює в материнській компанії та має переглядати дані учасників програми лояльності з усіх брендів одночасно в одному ресурсі. Цього можна досягти, якщо використовувати підпорядковані й зведені ресурси. Так команда матиме власний набір даних для роботи. Кожен первинний ресурс створить підпорядкований ресурс із даними лише про учасників, які беруть участь у програмі лояльності. Після цього всі три ресурси буде зведено для отримання даних про винагороди.

Схема, на якій показано два зведені ресурси

 

Глобальна компанія з регіонами та підрегіонами

У цьому прикладі глобальний корпоративний обліковий запис має 3 регіональні зведені підпорядковані ресурси, кожен із яких містить 2 первинні підпорядковані ресурси. 

Схема, на якій показано глобальний зведений ресурс і три регіональні зведені ресурси

Зв’язування облікових записів Google Ads, SA360 і DV360

У ресурсах Google Analytics 4 покращено функції зв’язування з Google Ads, однак їх суть не змінилася. Ви можете зв’язати свій обліковий запис Google Ads із ресурсом Google Analytics 4, щоб надсилати в Google Ads статистику щодо аудиторій і сайту, а також використовувати дані звітів Google Ads у ресурсі GA4. Зв’язування з обліковим записом Google Ads відбувається на рівні ресурсу Google Analytics. Ви можете зв’язати первинний, підпорядкований або зведений ресурс.

Важлива відмінність між Universal Analytics і Google Analytics 4: у Universal Analytics для експортування аудиторії потрібно вибирати кожен обліковий запис Google Ads (однак не більше ніж 10). У ресурсах GA4 всі зв’язані облікові записи мають спільну аудиторію. У зв’язку з цією зміною ділитися даними набагато простіше, однак надсилати потрібно всі аудиторії або не надсилати жодну. Пам’ятайте про це, створюючи аудиторії в Google Analytics 4.

Якщо зв’язати ресурс GA4 з обліковим записом Google Ads, ви зможете переглядати статистику сайту в Google Ads. Ця функція експортує дані про поведінку користувачів із Google Analytics прямо в інтерфейс користувача Google Ads. Ви можете налаштувати зв’язок із будь-яким типом ресурсу, однак рекомендуємо вибирати лише один первинний або підпорядкований ресурс (не обидва). Так ви уникнете подвійного зарахування, що трапляється, якщо зв’язати обидва ресурси.

У Google Ads можна надсилати аудиторії з будь-якого типу ресурсу GA4 (звичайного, підпорядкованого або зведеного), однак пам’ятайте, що аудиторія з підпорядкованого або зведеного ресурсу матиме дані, які відрізнятимуться від даних первинного (звичайного) ресурсу через фільтрування або використання кількох наборів даних. Звертайте на це увагу, використовуючи націлювання на аудиторію в Google Ads.

Так само конверсії залежать від зв’язаного типу ресурсу. Якщо ви не хочете імпортувати той самий тип конверсії з первинного, підпорядкованого й зведеного ресурсу, радимо зв’язати первинний ресурс GA з обліковим записом Google Ads і експортувати конверсії лише з цього джерела. Виняток становлять облікові записи Google Ads із регіональними оголошеннями, які потрібно зв’язувати на рівні ресурсу.

Дані з Google Ads додаються в ресурс Google Analytics 4 під час запиту. Це забезпечує актуальність даних, а також допомагає уникнути дублювання або зведення даних у підпорядкованих і зведених ресурсах.

Search Ads 360

Під час першого запуску інтеграція SA360 підтримуватиме успадкування даних із первинного до підпорядкованого чи зведеного ресурсу. Тобто, якщо зв’язок установлено в первинному ресурсі, то підпорядкований або зведений ресурс отримуватиме дані із SA360, однак не зможе контролювати чи налаштувати саме зв’язування.

Важлива відмінність між Universal Analytics і Google Analytics 4: у Universal Analytics для експортування аудиторії потрібно вибирати кожен обліковий запис (однак не більше ніж 10). У ресурсах Google Analytics 4 всі зв’язані облікові записи матимуть спільну аудиторію. У зв’язку з цією зміною ділитися даними набагато простіше, однак надсилати потрібно всі аудиторії або не надсилати жодну. Пам’ятайте про це, створюючи аудиторії в Google Analytics 4.

Display & Video 360

Під час першого запуску інтеграція DV360 підтримує успадкування даних із первинного до підпорядкованого чи зведеного ресурсу. Тобто, якщо зв’язок установлено в первинному ресурсі, то підпорядкований або зведений ресурс отримуватиме дані з DV360, однак не зможе контролювати чи налаштувати саме зв’язування.

Важлива відмінність між Universal Analytics і Google Analytics 4: у Universal Analytics для експортування аудиторії потрібно вибирати кожен обліковий запис (однак не більше ніж 10). У ресурсах Google Analytics 4 всі зв’язані облікові записи мають спільну аудиторію. У зв’язку з цією зміною ділитися даними набагато простіше, однак надсилати потрібно всі аудиторії або не надсилати жодну. Пам’ятайте про це, створюючи аудиторії в Google Analytics 4.

Інші приклади

Інтернет-магазин, який продає товари через веб-сайт і додаток у різних географічних регіонах

 

Ця велика корпорація працює в кількох географічних регіонах, кожен із яких має власну комерційну структуру. Кожний регіон має свій веб-сайт, маркетингову команду й обліковий запис Google Ads. Корпорація також має додаток (для iOS і Android).

Вимоги до компанії

Структура облікового запису має відповідати наведеним нижче вимогам.

  • Корпорація повинна мати глобальне представлення даних усіх комерційних структур.
  • Кожній комерційній структурі не обов’язково мати юридичне право власності на свої дані.
  • Кожна комерційна структура хоче розуміти, який шлях користувач проходить на веб-сайті та в додатку.
  • Кожній комерційній структурі потрібно категоризувати свої дані.
  • Маркетингова команда для кожної комерційної структури використовує зв'язок між продуктами Google Ads і Analytics, щоб створювати аудиторії, надавати до них доступ, а потім використовувати їх для призначення ставок у Google Ads.

Структура облікового запису

Принципи використання (стандартний обліковий запис)
  • Обліковий запис: один. Дані належать одній юридичній особі.
  • Ресурс: по одному ресурсу для однієї логічної бази користувачів.
  • Потоки даних: один потік для веб-сайту й по одному потоку даних для кожної версії додатка.
Принципи використання (обліковий запис 360)
  • Обліковий запис: один. Дані належать одній юридичній особі.
  • Ресурс: по одному ресурсу для однієї логічної бази користувачів.
  • Підпорядковані ресурси: один такий ресурс для кожної комерційної структури, якій потрібно категоризувати дані.
  • Потоки даних: один потік для веб-сайту й по одному потоку даних для кожної версії додатка.
Структура Пояснення

Один обліковий запис Analytics.

Якщо у вас уже є обліковий запис Analytics, не потрібно створювати ще один.

Головна компанія має юридичне право власності на дані всіх своїх комерційних структур.

Один ресурс Google Analytics 4.

Якщо у вас буде один ресурс із кількома окремими потоками даних для кожного сайту й додатка, усі ці дані можна буде включати в ті самі звіти. За потреби можна поєднати дані для веб-сайтів і додатків, щоб побачити, як користувачі переходять між ними. Корпорація має загальний огляд усіх даних і може порівнювати дані різних комерційних структур.

Підпорядкований ресурс для кожної регіональної команди (360).

Кожна регіональна структура має власний підпорядкований ресурс із даними, розділеними на категорії. Корпорація має загальний огляд усіх даних у первинному ресурсі й може порівнювати дані різних комерційних структур.

Один потік даних для веб-сайтів усіх регіональних комерційних структур.

Один потік даних веб-сайту можна використовувати для кількох доменів.

Один проект Firebase на обидва варіанти додатка (для Android і для iOS), зв’язаний із ресурсом Google Analytics 4.

Два потоки даних – по одному на кожен варіант додатка (для Android і для iOS).

За допомогою окремого потоку даних для кожної версії додатка можна відокремити дані з пристроїв iOS і Android.

 

Кожний обліковий запис Google Ads зв’язано з ресурсом (стандартна версія).

Коли всі облікові записи Google Ads зв’язано з тим самим ресурсом, у кожному з них можна призначати ставки на основі аудиторій із цього ресурсу.

Необов’язково: кожний обліковий запис Google Ads зв’язано з відповідним підпорядкованим ресурсом (360).

Коли всі облікові записи Google зв’язано з їх відповідним підпорядкованим ресурсом, у кожному з них можна призначати ставки на основі аудиторій із цього ресурсу.

 

Міжнародна студія з кількома іграми в Google Play та App Store

 

Ця компанія має один міжнародний фірмовий веб-сайт і окремі маркетингові сайти для кожної гри. Вона продає кілька ігор у магазинах Google Play та App Store.

Вимоги до компанії

Структура облікового запису має відповідати наведеним нижче вимогам.

  • Можливість збирати власні дані з веб-сайтів і додатків, щоб створювати аудиторії та обґрунтованіше купувати медійні рекламні ресурси.
  • Окреме середовище для розробки, налагодження та випуску кожної гри.

Структура облікового запису

Принципи використання (стандартні облікові записи)
  • Обліковий запис: один. Дані належать одній юридичній особі.
  • Ресурс: по одному ресурсу для кожної логічної бази користувачів (міжнародний фірмовий сайт; маркетинговий сайт і додаток для кожної гри).
  • Потоки даних: один потік даних для міжнародного фірмового веб-сайту. По одному потоку даних для кожного маркетингового сайту та кожної відповідної версії додатка.
Принципи використання (360)
  • Обліковий запис: один. Дані належать одній юридичній особі.
  • Ресурс: по одному ресурсу для кожної логічної бази користувачів (міжнародний фірмовий сайт; маркетинговий сайт і додаток для кожної гри).
  • Зведений ресурс: один такий ресурс збирає дані з усіх окремих первинних ресурсів, щоб дати вам цілісну картину.
  • Потоки даних: один потік даних для міжнародного фірмового веб-сайту. По одному потоку даних для кожного маркетингового сайту та кожної відповідної версії додатка.
Структура Пояснення

Один обліковий запис Analytics.

Якщо у вас уже є обліковий запис Analytics, не потрібно створювати ще один.

Об’єднує ресурси в єдиному обліковому записі, що належить одній юридичній особі.

Один ресурс Google Analytics 4 для міжнародного сайту бренду, один потік веб-даних.

Окреме відстеження показників для міжнародного сайту бренду.

По одному ресурсу Google Analytics 4 для кожної гри (маркетингового сайту й додатка). Кожен ресурс має включати один потік веб-даних і два потоки даних додатка – для iOS і для Android.

Дані із сайту й додатків, пов’язаних з одною грою, збираються в одному ресурсі.

На основі даних із пов'язаних сайту й додатка можна створювати аудиторії та обґрунтованіше купувати медійні рекламні ресурси.

По одному проекту Firebase для кожної гри, зв'язаному з відповідним ресурсом. Кожен проект Firebase включає версію на етапі розробки, а також налагоджувальну та робочу версії гри.

Окремий проект Firebase забезпечує окреме середовище для розробки, налагодження та випуску кожної гри.

Необов'язково. Окремий проект Firebase для кожної версії гри чи для деяких комбінацій версій. Наприклад, один проект для версії на стадії розробки, а інший – для налагодження та випуску.

Ви також можете поділити середовища кожної гри за проектами, але для цього потрібно більше ресурсів, якщо ви хочете відстежувати версію гри, зв’язану з конкретним проектом.

Необов’язково: зведений ресурс. Кожний первинний ресурс входить у зведений, який дає цілісне уявлення про дані з веб-сайту й додатка.

Ви також можете поділити середовища кожної гри за проектами, але для цього потрібно більше ресурсів, якщо ви хочете відстежувати версію гри, зв’язану з конкретним проектом.

 

Страхова компанія національного рівня з кількома незалежними дочірніми компаніями (страхування життя, здоров'я, домовласників, автотранспорту)

 

Ця компанія має один корпоративний веб-сайт для надання інформації клієнтам і визначення кола потенційних клієнтів. Для укладення договорів потрібна взаємодія офлайн (наприклад, телефоном, поштою або через POS-термінал). Кожна дочірня компанія має свій веб-сайт, окрему маркетингову команду та власний обліковий запис Google Ads.

В однієї дочірньої компанії (страхування автотранспорту) також є додаток.

Вимоги до компанії

Структура облікового запису має відповідати наведеним нижче вимогам.

  • Дані належать одній комерційній структурі в конкретному регіоні.
  • Дані з корпоративного сайту мають бути доступними для аналізу, який допоможе ефективніше визначати коло потенційних клієнтів і оптимізувати контент.
  • Кожній дочірній компанії потрібно розділяти дані на категорії, щоб відповідна маркетингова команда могла створювати аудиторії та відстежувати конверсії, пов’язані з її обліковим записом Google Ads.

Структура облікового запису

Принципи використання (стандартний обліковий запис)
  • Обліковий запис: один. Дані належать одній юридичній особі.
  • Ресурс: по одному ресурсу для кожної логічної бази користувачів (корпоративний сайт; сайт і додаток кожної дочірньої компанії).
  • Потоки даних: один потік даних для корпоративного веб-сайту. По одному потоку даних для кожного сайту дочірніх компаній, а також по одному – для кожної відповідної версії додатка.
Принципи використання (360)
  • Обліковий запис: один. Дані належать одній юридичній особі.
  • Ресурс: один ресурс для всіх сайтів і додатків (корпоративний сайт, сайт і додаток кожної дочірньої компанії).
  • Підпорядковані ресурси: по одному такому ресурсу для кожної логічної бази користувачів (корпоративний сайт, сайт і додаток кожної дочірньої компанії).
  • Потоки даних: один потік даних для корпоративного веб-сайту. По одному потоку даних для кожного сайту дочірніх компаній, а також по одному – для кожної відповідної версії додатка.
Структура Пояснення

Один обліковий запис Analytics.

Якщо у вас уже є обліковий запис Analytics, не потрібно створювати ще один.

Дані належать одній комерційній структурі в конкретному регіоні.

Один ресурс Google Analytics 4 з одним потоком веб-даних для корпоративного сайту (стандартний обліковий запис).

Маючи один ресурс і потік даних для корпоративного сайту, можна ефективніше визначати коло потенційних клієнтів та оптимізувати контент.

Для кожного сайту дочірньої компанії (стандартний обліковий запис):

один ресурс Google Analytics 4 з одним потоком веб-даних;

для ресурсу дочірньої компанії з автострахування – також потік даних додатка для Android.

Окремі ресурси та потоки даних для кожного сайту дочірньої компанії допомагають розділяти дані компаній.

Дані додатка й сайту дочірньої компанії з автострахування будуть доступні в одному ресурсі.

Один ресурс Google Analytics 4 з одним потоком веб-даних для всіх веб-сайтів (корпорацій і дочірніх компаній) (360).

Маючи один ресурс і потік даних для всіх веб-сайтів, можна ефективніше визначати коло потенційних клієнтів та оптимізувати контент. Це також дає змогу створювати підпорядковані ресурси на основі первинного.

Підпорядковані ресурси для кожного дочірнього й корпоративного сайту.

Ви можете створити підпорядкований ресурс, щоб відфільтрувати кожну логічну комбінацію даних (корпоративного або дочірнього сайту) у власному представленні.

Один проект Firebase для додатка Android дочірньої компанії з автострахування.

Проект Firebase, зв’язаний із ресурсом дочірньої компанії з автострахування (стандартний обліковий запис) або первинним ресурсом (обліковий запис 360).

Проект Firebase для додатка автострахування створює окреме середовище для розробки додатків.

Якщо зв’язати проект Firebase і ресурс дочірньої компанії, у цьому ресурсі будуть доступні дані з додатка й веб-сайту (те саме стосується первинного ресурсу для облікових записів 360).

Облікові записи Google Ads зв’язано з ресурсами дочірніх компаній (стандартні облікові записи) або підпорядкованими ресурсами (облікові записи 360).

Якщо зв’язати ресурс кожної дочірньої компанії з її обліковим записом Google Ads, то аудиторії з ресурсів будуть доступні у відповідних облікових записах Google Ads, а дані про конверсії з Google Ads – у відповідних ресурсах Google Analytics 4.

 

Заклад освіти/освітня організація

 

Ця організація має один веб-сайт і один обліковий запис Google Ads.

Вимоги до компанії

Структура облікового запису має відповідати наведеним нижче вимогам.

  • Студенти переглядають пропоновані курси, реєструються, проходять курс, а також керують навчанням в Інтернеті.
  • Для маркетингової команди важливо створювати аудиторії для ремаркетингу та визначати коло потенційних клієнтів.
  • Аналітикам потрібно знати, як ресурс використовується на різних пристроях, щоб вирішити, чи варто створювати мобільний сайт або додаток.

Структура облікового запису

Які принципи застосовуються
  • Обліковий запис: один. Дані належать одній юридичній особі.
  • Ресурс: по одному ресурсу для кожної логічної бази користувачів (веб-сайт закладу).
  • Потоки даних: один потік даних для веб-сайту закладу.
Структура Пояснення

Один обліковий запис Analytics.

Якщо у вас уже є обліковий запис Analytics, не потрібно створювати ще один.

Дані належать одній організації в конкретному регіоні.

Один ресурс Google Analytics 4 з одним потоком веб-даних.

В одному ресурсі буде зручно зібрано всі дані про сайт.

Маркетологи зможуть створювати аудиторії на основі будь-яких комбінацій показників і параметрів.

Аналітики зможуть відстежити, як люди користуються сайтом на різних пристроях, і визначити, чи потрібен мобільний сайт або додаток.

Один обліковий запис Google Ads, зв’язаний із ресурсом Google Analytics 4.

Маркетологи зможуть експортувати аудиторії в Google Ads для ремаркетингу та визначення кола потенційних клієнтів.

 

Туристична компанія з кількома брендами, що працює в різних країнах

 

У цієї компанії є кілька брендів. Кожен має веб-сайт для настільних комп'ютерів, мобільний сайт і додаток, а також власні маркетингову команду й рекламні облікові записи.

Вимоги до компанії

Структура облікового запису має відповідати наведеним нижче вимогам.

  • Дані потрібно аналізувати за країною.
  • Кожній маркетинговій команді потрібно створити власні аудиторії та відносити конверсії до зв'язаних рекламних облікових записів.

Структура облікового запису

Принципи використання (стандартний обліковий запис)
  • Обліковий запис: один. Дані належать одній юридичній особі.
  • Ресурс: по одному ресурсу для кожної логічної бази користувачів (корпоративний сайт; сайт і додаток кожного бренду).
  • Потоки даних: один потік даних для корпоративного веб-сайту. Один потік даних для сайту кожного бренду, а інший – для кожної відповідної версії додатка.
Принципи використання (обліковий запис 360)
  • Обліковий запис: один. Дані належать одній юридичній особі.
  • Ресурс: по одному ресурсу для кожної логічної бази користувачів (корпоративний сайт; сайт і додаток кожного бренду).
  • Зведений ресурс: один такий ресурс для спільного перегляду всіх наборів географічних даних і даних організації.
  • Потоки даних: один потік даних для корпоративного веб-сайту. Один потік даних для сайту кожного бренду, а інший – для кожної відповідної версії додатка.
Структура Пояснення

Один обліковий запис Analytics.

Якщо у вас уже є обліковий запис Analytics, не потрібно створювати ще один.

Дані належать одній комерційній структурі.

По одному ресурсу Google Analytics 4 для кожного бренду. Кожен ресурс має включати:

  • один потік веб-даних із сайту бренду;
  • по одному потоку даних для кожного варіанта додатка бренду (для Android і для iOS).

Маючи для кожного бренду окремий ресурс, можна:

  • аналізувати показники для різних брендів і країн;
  • створювати аудиторії на основі бази користувачів для певних бренду та країни;
  • відносити конверсії до зв’язаних рекламних облікових записів.

Окремі потоки даних для кожної платформи дають змогу проводити комплексний, порівняльний або індивідуальний аналіз даних і формувати аудиторії, орієнтовані на платформу.

Один зведений ресурс, який об’єднує всі ресурси бренду (облікові записи 360).

Об’єднавши всі первинні ресурси у зведений, ви матимете цілісне уявлення про дані на рівні установи.

Облікові записи Google Ads, Display & Video 360 і Search Ads 360, зареєстровані для бренду, зв’язані з відповідними ресурсами.

Кожній маркетинговій команді потрібно створити власні аудиторії та відносити конверсії до зв'язаних облікових записів у рекламних продуктах.

 

Чи корисна ця інформація?
Як можна її покращити?
false
Пошук
Очистити вікно пошуку
Закрити пошук
Додатки Google
Головне меню
Пошук у довідковому центрі
true
69256
false
false