Откриване на грешки в интеграцията без промяна на статистиката

Отстраняване на грешки при измерване проверява дали предложено събитие би било прието за собствен брояч. Не изпраща нормално събитие и не увеличава общите стойности за посетители, цели, събития или приходи. Това е полезно за грешки в конфигурацията, като се запазва разграничението между диагностичен резултат и реално измерване.

Първа диагностична проверка

1. Броячът се свързва чрез Моите броячи и се отваря Табло и инструменти.
2. Отваря се Отстраняване на грешки при измерване. В Име на събитието се въвежда устойчива стойност, например signup за ръчно събитие.
3. Избира се съответният Тип измерване и дали името на събитието се генерира автоматично. Успех на форма и ръчно събитие използват различни настройки.
4. Предварително определени свойства (JSON обект, незадължително) се оставя като {}, освен ако предварително определени свойства действително са конфигурирани. Никога не се въвеждат съдържание на форма или лична информация.
5. Избира се Проверка без отчитане и се прочитат резултатът и нормализираното име на събитието.

Тълкуване на отказа преди промяна на кода

Изключена автоматична категория изисква активиране на съответната настройка за измерване. Невалидно име или име, приличащо на лични данни, изисква устойчиво име на категория вместо идентификатор на посетител. Лимитът за нови имена означава, че непрекъснатото измисляне на имена на събития няма да реши проблема. Проверява се показаният на страницата резултат, вместо да се предполага, че всички неуспехи са мрежови грешки.

Свойствата трябва да съответстват на предварително определената конфигурация. Диагностиката съобщава за приемането им, без да повтаря изпратените стойности. Информацията за цели различава съвпадаща цел от отчетено човешко посещение: само конфигурирана цел не гарантира добавяне на посетител на целта.

Проверка на диагностичната връзка от сайта

1. В Проверка на собствения сайт се използва Копиране на кода за проверка за копиране на генерирания диагностичен код.
2. Отваря се собственият сайт, съдържащ брояча, и кодът се изпълнява в инструментите за разработчици на браузъра според описанието на страницата на дебъгера.
3. Прочита се резултатът в конзолата. Генерираното тестово разрешение изтича след петнадесет минути; страницата на дебъгера за собственика се презарежда при нужда от ново.

Използва се генерираното временно разрешение, а не частният ключ на собственика в ръчно написан скрипт. Промяната на ключа на собственика обезсилва и диагностичното разрешение. Диагностичната крайна точка ограничава заявките, но не създава нормални данни за проследяване.

Отделна проверка на нормалната интеграция

Приета диагностика означава, че предложеното събитие би било допустимо в този момент. Тя не проверява лимита за честота на нормалното проследяване, последващи записи в базата данни, блокиране от браузъра, засягащо нормалната заявка, успешна обработка на форма или последователен напредък във фуния.

1. Проверява се дали s4u.js се зарежда на предвидената страница на сайта и дали нормалните заявки за проследяване се блокират или се провалят.
2. Проверяват се номерът на брояча, активната категория и периодът на отчета.
3. При форма се потвърждава действителната успешна обработка от приложението, преди да се очаква събитието ѝ за успех.

Във всеки доклад за грешка диагностичният резултат и резултатът от нормалната заявка се държат отделно. Липсващо измерване не може да се обясни надеждно с един зелен диагностичен отговор.

Следваща стъпка

Отваряне на собствения брояч и начало с диагностично събитие без лични данни.

Отваряне на собствените броячи