Вашият GA4 имот отчита 4,180 покупки миналия месец. Таблицата ви с поръчки показва 4,690. На въпроса кое е правилно, честният отговор е нито едното, докато не можете да кажете къде са отишли липсващите 510 поръчки. Това не е проблем с подредеността. Всеки резултат от експеримента и всеки резултат от приоритизацията, който генерирате, се изчислява въз основа на число, което е грешно с неизвестна стойност в неизвестна посока.
Google третира голям неизмерен сегмент като нормално: поведенческото моделиране за режим на съгласие не се включва, докато дадено свойство не запише поне 1,000 събития на ден с analytics_storage='denied' за поне 7 дниПод това ниво липсващите данни си остават липсващи.
Това е за всеки, който притежава аналитика или CRO в екип за електронна търговия. Накрая ще имате таблица за съгласуване, разлагане на вашата разлика по посочени причини с тест за всяка и допустима стойност, която можете да защитите.
Какво всъщност измерва съгласуването на покупките
Съгласуването не е „да накараш числата да съвпадат“. Те никога няма да съвпаднат и екип, който ги принуждава да го правят, обикновено е направил нещо по-лошо от това да остави разликата така, както е. То отговаря на три въпроса: колко голяма е разликата, кои посочени механизми я създават и колко е възстановимо на каква цена. Изпълняваме го преди всяко експериментално действие, защото тест, измерен върху събитие за конверсия, което тихо отпада неизвестен дял от поръчките, не е експеримент.
Стъпка 1: издърпайте две таблици, които могат да бъдат съединени по идентификатор на поръчката
Необходим ви е по един ред на поръчка, от двете системи, за един и същ календарен диапазон, с ключ, който съществува и от двете страни.
- бекенда: идентификационен номер на поръчката, времеви клеймо на създаването в отчетната часова зона на имота, стойност на поръчката на същата данъчна и доставка база, която сте конфигурирали в GA4, начин на плащане, устройство, държава, статус.
- GA4: експортът в BigQuery, а не потребителският интерфейс. Заявка
purchaseсъбития сecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue, категория устройство и източник на трафик.
Използвайте BigQuery целенасочено. Моделираните данни от режима на съгласие се появяват в стандартните отчети на GA4 и някои проучвания, но Google заявява, че е така. не в експорта на BigQuery, аудитории, изследовател на потребители, изследвания на кохорти или задържане или прогнозни показатели. Сравнете потребителския интерфейс с таблицата си с поръчки и ще сравните оценка с факт.
След това пълно външно съединение по идентификатор на поръчката. Сега имате три контейнера: и в двата, само за backend, само за GA4. Третият е по-малък, но най-диагностичен.
Стъпка 2: изразете празнината по три начина, а не по един
Един единствен месечен процент крие всичко. Изчислете и трите:
- Разлика в броя на поръчките: (поръчки от бекенд минус съвпадащи покупки от GA4) / поръчки от бекенд. Това изолира загубата на проследяване.
- Разлика в приходите: Същото изчисление и за стойността. Ако разликата в броя е 3%, а разликата в приходите е 11%, нямате проблем с проследяването, а проблем с дефинирането на стойността (данъци, доставка, отстъпки, валута, подаръчни карти).
- Дневна дисперсия на разликата: Начертайте разликата в броя на поръчките за деня. Плоската линия означава структурна причина, като например съгласие или блокиращи фактори. Пиковете означават внедрявания, пикове на кампании или инцидент с доставчик на плащания.
Стъпка 3: Разделете празнината на посочени причини
Разгледайте тази таблица. Всяка причина има тест, който може да я потвърди или елиминира за по-малко от час.
| Причина | Как да го тествам | Подпис в данните |
|---|---|---|
| Съгласието е отказано, етикетът никога не се задейства | Сравнете дневника на състоянието на съгласие на вашата CMP със сесиите в GA4 за същия период | Стабилен дневен процент; концентриран в трафика от ЕС и Турция |
| Блокери на реклами и тракери | Пребройте заявките към сървърния лог за URL адреса за потвърждение и ги сравнете със събитията за покупка в GA4 на този URL адрес. | Skews настолен браузър, Firefox и браузъри за поверителност; стабилен във времето |
| Страницата за потвърждение никога не се зарежда | Брой поръчки само за бекенд, чийто URL адрес за потвърждение никога не е бил заявен в сървърните лог файлове | Концентриран в банкови пренасочвания и 3DS методи на плащане |
| Дублиращи се събития за покупка | Брой събития за покупка в GA4 на transaction_id | GA4 превъзхожда backend-а в някои дни; страници с много обновяване и бутон „Назад“ |
| Междудомейновата връзка е прекъсната | Проверете дали _gl преживява обратния път от доставчика на плащания | Покупките се осъществяват в нови сесии, приписани на платежния домейн като препратка |
| Нулиране на живота на бисквитките | Сегментиране на процента на новите потребители по браузър | Завишени нови потребители и директен трафик в Safari и iOS |
| Моделирано срещу сурово | Сравнете общите стойности от потребителския интерфейс на GA4 с BigQuery за идентичен период от време | Двете числа в Google не съвпадат, още преди да отворите таблицата с поръчки |
| Определение на стойността | Преизчислете приходите от бекенд системата със и без данъци, доставка и отстъпки | Броят съвпада, приходите не |
| Граница на часовата зона | Преагрегиране до цели седмици | Разликата се свива към нула при седмична гранулация |
Двама заслужават допълнителни грижи. transaction_id Дедупликацията работи само за уеб потоци, не за потоци от приложения, а Google предупреждава, че изпращането на празен низ кара Analytics да дедублира всеки провеждане на събитие за покупка transaction_id=''Този един бъг може да заличи по-голямата част от деня. Отделно, списъкът с нежелани препратки е ограничен до 50 домейна на поток от данни, което е малко вероятно, ако използвате няколко придобиващи компании, портфейли и банкови страници.
[НЕОБХОДИМИ ВЪТРЕШНИ ДАННИ: наблюдаваното разпределение на тези девет причини в рамките на ангажиментите за помирение на Switas, така че читателите да могат да видят кои от тях обикновено доминират.]
Стъпка 4: задайте толеранс, който можете да защитите
Google не публикува приемлива стойност за несъответствие, а широко цитираното „5% е добре“ не се появява в нито една документация на Google, която не успяхме да намерим. Задайте своя собствена, обусловена от разлагане, а не само от числото.
| Месечна разлика в броя на поръчките | четене | действие |
|---|---|---|
| До 2% | Граници на часовите зони и нормално дедупликиране | Запишете причините, проверявайте отново всяко тримесечие |
| 2% до 5% | Приемливо само ако всяка точка е приписана на посочена кауза | Документирайте, след което продължете с експериментирането |
| 5% до 10% | Поне една структурна причина е неотстранена | Коригирайте, преди да се доверите на абсолютните числа за реализациите |
| Над 10% | Не е подходящ за експерименти | Спрете да използвате покупки в GA4 като основен показател за експеримента, докато проблемът не бъде отстранен |
Това са нашите оперативни прагове, а не индустриален стандарт. Квалификаторът е същината: необясними 3% са по-лоши от обяснени 8%.
Стъпка 5: поправете поръчката, която възстановява най-много поръчки на час работа
- Дефиниция на стойност и часова зона. Конфигурация, не инженерство, и обикновено един следобед.
- Дубликати и празни идентификатори на транзакции. Една корекция на dataLayer.
- Междудомейни и нежелани препратки. Конфигурирайте и двете, след което тествайте отново пътя за връщане на плащане в реално време, а не поетапния.
- Събитие за покупка от страна на сървъра. Изпратете покупката от вашата система за поръчки с Measurement Protocol, използвайки
client_idгенериран от вашия уеб таг. Google изисква тези събития да се случват в рамките на 48 часа от оригиналния времеви отпечатък на събитието от страна на клиента, в противен случай атрибуцията може да не се обработи според очакванията. Това е, което възстановява поръчките, загубени поради блокиране, и страниците за потвърждение, които никога не са се рендирали. - Архитектура на съгласието. Най-бавният и най-политизиран. Останалите третирайте като известна, оразмерена, документирана празнина.
Какво се променя, ако продавате в Турция или ЕС
Два регионални факта влияят на числата.
Съгласието е по желание и в Турция, но без предпазната мрежа на Google. В решение 2022/1358 (23 декември 2022 г.) турският орган за защита на данните глоби оператор на уебсайт с 300 000 турски лири за използване на рекламни и маркетингови „бисквитки“ без правно основание и изисква активно съгласие за несъществени „бисквитки“. Много турски сайтове отговориха с банер, който блокира етикета на Google изцяло, вместо такъв, който изпраща сигнали за режим на съгласие. Това разграничение е скъпо: необходимо е моделиране. analytics_storage='denied' събития да съществуват. Банер, който не задейства нищо, не дава на Google основата за моделиране, така че данните изчезват, а не се оценяват.
Турските 3DS потоци връщат купувача по ПОЩАТА. С iyzico, търговецът генерира декодирана 3DS страница и след потвърждение с OTP, iyzico пренасочва към страницата на търговеца. callbackUrl с status, paymentId намлява mdStatusВръщането, управлявано от POST, е точно това, което Google нарича „нарушаване на междудомейното измерване“, тъй като пренасочванията могат да премахнат _gl преди дестинацията да се зареди. Ако разликата ви е в плащанията с карта и е близо до нула за наложен платеж, ето защо.
Две широко повтаряни твърдения, които не успяхме да проверим
Safari ограничава бисквитките на първа страна до 7 дни. Неточно. Документацията на WebKit казва, че ITP изтрива JavaScript бисквитките и други скриптово записваеми хранилища след 7 дни без взаимодействие с потребителяи отделно ограничава JavaScript „бисквитките“ до 24 часа, когато целевата страница е била достигната чрез декорация на връзка от класифициран домейн. Тестването на Симо Ахава установи, че часовникът работи на базата на дни на използване на браузъра, а не на календарни дни, така че един завръщащ се клиент може да запази идентификатор доста повече от седмица.
„Разминаване от 5% е приемливо.“ Не открихме източник в Google за тази цифра. Тя се разпространява чрез блогове на доставчици и отговори във форуми. Използвайте я като фолклор, а не като праг.
Къде този метод не работи
Това не обхваща потоци от приложения, където transaction_id Дедупликацията не се прилага, нито моделите с абонамент и частична доставка, където „поръчка“ не е едно събитие. Тя не може да възстанови самоличността на потребител, на когото е отказано съгласие, а само да оцени обема. Не коригира атрибуцията на канала, отделен и по-труден проблем. И приема, че таблицата ви с поръчки е чиста: ако анулираните и блокираните от измами поръчки се броят непоследователно от двете страни, ще търсите празнина, която съществува само във вашата заявка.
Често задавани въпроси
Колко често трябва да изпълняваме това? Пълно веднъж, след това дневна диаграма на разликите. Изпълнете отново пълното разлагане след всяка промяна на плащане, CMP, доставчик на плащания или мениджър на тагове.
Защо да не използваме интерфейса GA4 вместо BigQuery? Интерфейсът може да включва моделирани потребители и сесии, които експортът не включва, така че двете числа от Google не съвпадат. Съгласуването с приблизителна оценка прави невъзможно разлагането на разликата.
Ще запълни ли напълно празнината маркирането от страна на сървъра? Не. Възстановява поръчки, загубени поради блокиране и страници за потвърждение, които никога не са се рендирали. Не възстановява потребители, които са отказали съгласие.
GA4 е по-висок от нашия бекенд. Възможно ли е това? Да. Обикновено се случват дублирани събития за покупка от обновяване на страница, празна или повторно използвана transaction_idили поетапни поръчки за изстрелване в производствения имот.
Режимът на съгласие коригира ли разликата в съгласието на турците? Частично. Отхвърлените сигнали правят моделирането възможно, при спазване на праговете за обем на Google. То не е заместител на законния банер съгласно турските правила.
Какво се счита за добра празнина? Такова, където всеки процентен пункт си има име. Документираните 8% са по-добри от необяснимите 3%.
Трябва ли да преизчислим историческите отчети, след като поправим това? Не. Анотирайте датата на корекцията и третирайте периодите като отделни серии. Преформулирането на проследените реализации унищожава одитната следа.
Можем ли да провеждаме A/B тестове, докато разликата е над 10%? Изпълнете ги с относителни показатели, измерени в инструмента за тестване, но не отчитайте абсолютното въздействие върху приходите от GA4, докато разликата не бъде разложена.
Изпълнете това съгласуване в собствения си магазин този месец или Нека нашият екип за анализи го направи заедно с вас и ви давам разлагането, толеранса и реда за поправка.
Източници
- [GA4] Поведенческо моделиране за режим на съгласие, Помощ за Google Analytics
- [GA4] Минимизиране на дублиращите се ключови събития с идентификатори на транзакции, Помощ за Google Analytics
- [GA4] Нежелани препратки, Помощ за Google Analytics
- [GA4] Междудомейно измерване, Помощ за Google Analytics
- Изпращане на събития от Measurement Protocol до Google Analytics, Google for Developers
- Параметри на режима на съгласие, документация на Google Tag Platform
- Предотвратяване на проследяване в WebKit
- Премахнато е ограничение за срок на валидност от JavaScript бисквитките в браузърите WebKit, Симо Ахава
- KVKK Kurul karari 2022/1358, 23 декември 2022 г.
- 3DS внедряване, документация за разработчици на iyzico
