Към съдържанието

Tracking | SEO и атрибуция

Проверено

Анализи → Tracking | SEO отговаря на въпроса, на който Отчети не могат: доколко може да се вярва на тези числа.

Отчети казват колко е продадено. Tracking | SEO казва колко от това аналитиката е видяла и откъде е дошло. Това са два различни въпроса, затова са два екрана. Периодът, магазинът и режимът на ДДС при това са общи: преминаването между Отчети и Tracking не пренастройва нищо.

Екранът има четири раздела:

Раздел На какво отговаря
Преглед Колко поръчки и колко оборот е уловило измерването.
Канали и атрибуция Откъде са дошли поръчките.
SEO Как ни вижда търсачката.
Поръчки Разбивка по отделните поръчки.

Две истини, които не бива да се бъркат

Раздел „Две истини, които не бива да се бъркат“

Това е най-важното разграничение в целите Анализи.

  • Търговската истина е това, което наистина е продадено. Източник са поръчките на магазина. По нея се изчисляват оборотът, броят поръчки и всички финансови показатели.
  • Аналитичната истина е това, което е уловило измерването в браузъра. Тя винаги е по-малка: част от посетителите отказват измерването, част го блокират, а част от поръчките изобщо не възникват в уебсайта.

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

Покритие на поръчките и покритие на оборота

Раздел „Покритие на поръчките и покритие на оборота“

Две числа, които казват каква част от измерването работи:

  • Покритие на поръчките: от колко поръчки, при които може да се очаква следа в браузъра, аналитиката наистина е записала транзакция.
  • Покритие на оборота: каква част от оборота на същите поръчки е уловила.

И двете се показват и с точната стойност („82 от 115“, „8 389 € от 10 851 €“), а не само с процент.

Какво не се включва в покритието

Раздел „Какво не се включва в покритието“

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

По същия начин не се броят поръчки, по-млади от 48 часа: аналитиката допълва данните със задна дата и свежата поръчка все още може да бъде уловена.

Сравнение на магазините

Раздел „Сравнение на магазините“

Всеки свързан магазин има собствен ред с покритие и състояние на измерването. Състоянието е словесно, а не техническо:

Състояние Какво означава
В ред Измерването улавя преобладаващото мнозинство поръчки.
Следене Покритието е спаднало, но все още няма причина за намеса.
Недостатъчно измерване Липсва съществена част. Числата по канали за този магазин са непълни.
Без данни За периода няма от какво да се изчисли.

Праговете са общи за цялото приложение, а не зададени при всяка таблица поотделно.

Развитие във времето

Раздел „Развитие във времето“

Графика на покритието на поръчките и оборота по дни. Липсващият исторически запис не се изобразява като нула: ден без запис просто го няма в графиката. Нулата би твърдяла, че в този ден измерването не е уловило нищо, а това е различно твърдение от „тогава все още не сме измервали“.

Кога последно са изтеглени данните

Раздел „Кога последно са изтеглени данните“

Над числата има ред Последна синхронизация с часа за поръчките на магазина, GA4 и GSC. Той служи за едно-единствено нещо: да различите „измерването не е уловило поръчката“ от „аналитиката все още не е изтеглена“. Първото е находка, второто е само забавяне, а без тази информация лесно ще прочетете второто като първото и ще тръгнете да търсите грешка, която я няма. Източник, който никога не е изтеглян, е отбелязан.

Предупреждение за рязък спад на покритието

Раздел „Предупреждение за рязък спад на покритието“

Когато покритието за последния период рязко спадне спрямо обичайното, над числата се появява предупреждение с двете стойности. Това не е грешка в приложението: числата под него са верни, идват от поръчките на магазина. По-малко от тях са уловени от измерването, така че разпределението по канали за този период е по-непълно. Обичайните причини са прекъсване на измерването, промяна в съгласието за бисквитки или прекъснат импорт.

Сравнява се с медианата на предходните периоди, а не със средната стойност: една-единствена лоша седмица би свалила средната толкова, че следващото прекъсване вече не би задействало предупреждението. Периоди с малък брой поръчки не се включват в сравнението: последният ден обикновено е непълен и една-единствена неуловена поръчка от една иначе би съобщавала за прекъсване всеки ден.

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

Слой Кога поръчката принадлежи там
Засечено в анализа Аналитиката познава транзакцията. Каналът се взема от нея.
Приписано от MitoOps Аналитиката няма транзакцията, но има еднозначно доказателство: купон на партньор или код на кампания, класифициран в регистъра.
Некласифициран код Знаем точния код за отстъпка, само никой все още не е решил за него.
За проверка Сигнал има, но не е еднозначен: например два различни потвърдени кода в една поръчка.
Неприписано Нямаме никакво доказателство за произхода на поръчката.

Некласифицираният код не изчезва от отчета

Раздел „Некласифицираният код не изчезва от отчета“

Когато поръчката е използвала кода BF20 и все още никой не е решил какво означава този код, MitoOps все пак знае детерминиран факт: поръчката е използвала този код. Затова тя получава собствен ред

Код за отстъпка · BF20 · значка Некласифициран

с реалния брой поръчки и оборот. Не изчезва в анонимна група, от която оборотът не може да бъде проследен.

Когато по-късно класифицирате кода, редът при следващото изчисление сам се преименува на Кампания · Black Friday · BF20 или Партньорска програма · партньор · код, включително със задна дата, за исторически периоди. Поръчките при това не се променят. Променя се само начинът, по който се четат.

Защо нищо не се оценява

Раздел „Защо нищо не се оценява“

Липсващите поръчки никога не се разпределят между съществуващите канали пропорционално. Това би изглеждало по-точно, но би било измислено: ако прекъсването на измерването засегне точно един канал (което е обичайно след намеса в уебсайта), разпределението би го размазало между всички и би скрило точно това, което трябва да се вижда.

Неприписаната поръчка е правилен резултат, а не грешка. Смисълът на Tracking не е да твърди, че знаем всичко, а да отдели точно какво знаем и какво не.

Кога MitoOps приписва поръчката сам

Раздел „Кога MitoOps приписва поръчката сам“

Само когато има еднозначно структурирано доказателство, а аналитиката няма транзакцията. Редът е фиксиран:

  1. Аналитиката познава транзакцията → каналът е неин. Дори когато не може да каже канала: тогава това е Засечено, неизвестен канал. Купонът в такава поръчка не я презаписва. Иначе една и съща поръчка би се отчела два пъти с два различни произхода.
  2. Аналитиката няма транзакцията, а в поръчката има купон на партньор → Партньорска програма · име на партньора · код.
  3. Аналитиката няма транзакцията, а в поръчката има код на кампания → Кампания · име · код.
  4. Кодът е известен, но некласифициран → собствен ред Код за отстъпка · код със значка Некласифициран.
  5. В поръчката има два различни потвърдени кода → За проверка.
  6. Няма доказателство → Неприписано.

Кодът за отстъпка не означава автоматично партньорска програма. Решава това, което е записано за кода, а не как изглежда името му.

Вътрешните бележки не се анализират

Раздел „Вътрешните бележки не се анализират“

Бележката към поръчката е свободен текст, написан от човек. MitoOps никога не извлича атрибуция от нея: търсенето на име с регулярен израз е гадаене с приятно лице. Бележката може да помогне на мениджъра при ръчното решение, но не влиза в отчета като източник.

Таблицата Кодове за отстъпка показва всички кодове, които са се появили в поръчки през периода, класифицирани и некласифицирани. Разделите над таблицата превключват между Всички, Некласифицирани и Класифицирани, а полето за търсене намира кода и по името на класификацията. Кодът, който класифицирате, следователно не изчезва от екрана и може да бъде намерен по всяко време.

Може да се избере:

  • Партньорска програма: код на партньор,
  • Кампания: маркетингова акция,
  • Вътрешен: собствен код на служителите, а не маркетингов канал,
  • Игнорирай: съзнателно решение кодът да не се приписва.

Докато решението не бъде взето, поръчките с такъв код имат собствен ред Код за отстъпка · … със значка Некласифициран: оборотът и броят са реални, липсва само класификацията. Системата може да предложи класификация, но предложението никога не става правило само.

Две колони, които не бива да се бъркат

Раздел „Две колони, които не бива да се бъркат“

В таблицата при всеки код има две различни числа:

Колона Какво означава
Поръчки с кода Колко поръчки са съдържали този код.
Приписани Колко от тях MitoOps наистина е класифицирал според този код.

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

Пример от реални данни: кодът GROUNDING20 е бил в 5 поръчки на един магазин, но според него е приписана 1: останалите 4 аналитиката вече е познавала.

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

Собствена категория за атрибуция

Раздел „Собствена категория за атрибуция“

Петте класа по-горе са структура, а не списък на това как различавате своите източници. Който изпраща бюлетин, попъп и ремаркетинг, има три различни неща под едно име.

Затова в избора на класификация има опция + Собствена категория…. Прозорецът с име и незадължителен цвят се отваря веднага след избора: нищо не се потвърждава отделно. Когато затворите прозореца, без да създадете категория, изборът се връща към първоначалната класификация. След запазване категорията се добавя в менюто при всеки код за отстъпка, а кодът, от който сте я създали, се класифицира в нея веднага. В отчета тя получава ред име на категорията · код.

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

Можете да я преименувате там, където я избирате: в избора на класификация има опция Управление на собствените категории (показва се само когато имате поне една). Тя отваря прозорец със списък. При всяка има Редактиране, което заменя името с поле. Новото име важи със задна дата за целия период: поръчките и оборотът не се променят, а суровите данни от аналитиката (източник, канал, препращаща страница) не се променят изобщо. Две еднакви имена не се запазват: в отчета биха възникнали два реда, които никой не може да различи.

Категорията, която престанете да използвате, архивирате (престава да се предлага). Не може да бъде изтрита, докато в нея е класифициран код: иначе старият отчет не би могъл да каже към какво е била класифицирана поръчката.

Купоните, издадени от партньор чрез модула Партньорска програма, не попадат тук: те са класифицирани още със самото си съществуване.

Посещенията не се измислят

Раздел „Посещенията не се измислят“

При канал, възникнал от собствен сигнал за атрибуция, аналитиката не е записала никакво посещение. В колоната Посещения затова стои тире, а не нула. Нулата би твърдяла, че никой не е дошъл.

Посещаемостта от AI търсачки (ChatGPT, Claude, Perplexity, Gemini, Copilot, Grok) има собствени редове и общ ред със сбора. Редът със сбора не се включва втори път в общите числа: той е обобщение на редовете над него, а не още един канал.

Когато аналитиката не е свързана

Раздел „Когато аналитиката не е свързана“

Без свързана аналитика покритието не може да бъде изчислено и MitoOps казва това, вместо да покаже нула.

Нулата би означавала „измерването се е провалило при всяка поръчка“. Това е нещо съвсем различно от „измерването никога не е работило“ и би Ви накарало да търсите повреда там, където е достатъчно да свържете акаунта.

В такова състояние:

  • покритието на поръчките и оборота е тире, а не 0 %,
  • Прегледът в Отчети пише Покритието на трекинга не е достъпно и предлага връзка за свързване,
  • Каналите носят предупреждение, че атрибуцията е непълна,
  • търговските числа остават: оборотът и броят поръчки идват от магазина и нямат връзка с аналитиката.

Същото важи за период, за който данните от аналитиката все още не са изтеглени.

Данни от Search Console: кликове, показвания, CTR и средна позиция: общо, по магазини и в разбивка по заявки, страници, държави или устройства.

До 22. 8. 2026 тази област беше в Прегледа на Отчети. Преместена е тук, защото е измерване, а не финансов резултат.

Разбивка по отделни поръчки: номер на поръчката, магазин, дата, сума, състояние и дали аналитиката я е уловила.

Без клиентски данни. В таблицата няма име, имейл, телефон или адрес: атрибуцията не се нуждае от тях и отчетните таблици не ги съхраняват.

Състоянията са същите като досега: Заснета, Изпратена от сървъра, Липсва в GA4, Проследяване не се очаква, Чакат се данни, Неизвестен статус. При оценката гледайте Липсва в GA4: останалите намаляват покритието законно.

При всяка поръчка се вижда къде я е класифицирал отчетът: канал от аналитиката (Organic, Direct, Paid Google…), собствен сигнал (Партньорска програма · име · код, Кампания · име · код, име на собствена категория · код), Код за отстъпка · … при некласифициран код, За проверка при спор или Неприписано.

Под стойността има значка на източника: GA4, когато класификацията е определена от аналитиката, името на приложението, когато е определена от собствен сигнал, или без източник, когато класификация нямаме. Колоната преди се наричаше Приписване (MitoOps), макар в нея да се показваха и канали от аналитиката: името следователно твърдеше нещо различно от съдържанието.

Полето над таблицата търси по номер на поръчката, код за отстъпка и име на атрибуцията (тоест и на канала). Напишете GROUNDING20, Newsletter или Direct и списъкът се стеснява до съответните поръчки в избрания период.

По име, имейл, телефон или адрес на клиента не се търси и екранът не ги показва: намирането на конкретен човек е работа на Поръчки, а не на измерването.

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

Името на партньора е лични данни. Който има право на Tracking, но не и на Партньорска програма, вижда класификацията без името. Кодът остава, така че поръчката може да бъде намерена. Складовият работник и поддръжката изобщо нямат достъп до списъка.

Tracking | SEO е обвързан с правото Тракинг и атрибуция, което е отделено от правото за Отчети и от Разходи на фирмата.

Благодарение на това може да се състави роля, която вижда каналите, атрибуцията и SEO, но не вижда брутната печалба, покупните цени и фирмените разходи. Настройва се в Настройки → Потребители.

  • Покритието е ниско. Вижте колко от него е Липсва в GA4. Ръчните и свежите поръчки намаляват покритието законно.
  • Много поръчки са Неприписани. Това означава, че нямаме доказателство за произхода им. Помага по-високо покритие на измерването или класифициране на кодовете за отстъпка, които използвате.
  • На партньора му се падат повече поръчки, отколкото в отчета. Отчетът за партньорската програма и отчетът по канали отговарят на различни въпроси. Когато аналитиката познава транзакцията, каналът е неин: партньорът може да има право на комисиона, но втора продажба в отчета не възниква.
  • Каналът няма посещения. Каналите от собствен сигнал за атрибуция нямат записано посещение. Тирето е правилният отговор.
  • Графиката на развитието е празна. За периода все още няма исторически записи. Те се създават ежедневно.