Campaign Evidence: інтегрований звіт і Reconciliation

Модуль 10 · Урок 33 із 34

Campaign evidence: інтегрований звіт і reconciliation

Зберіть organic, paid, web і community evidence в один відтворюваний звіт без подвійного рахунку, підміни scope або вигаданих причин.

Campaign defense pack

Десять безпечних файлів: evidence ledger, timeline, reconciliation, community cases, findings, executive outline, next-cycle plan, negative fixtures і validator. Усі дані synthetic; real account, spend або PII відсутні.

Завантажити campaign defense pack →

Захист починається не зі слайдів

Підсумковий звіт не є колекцією найпривабливіших графіків. Це контрольований ланцюг від запитання бізнесу до джерела, визначення метрики, спостереження, обмеження й рішення. Спочатку зафіксуйте reporting contract: кампанію, період, часовий пояс, валюту, рівень сутності, attribution window, дату зрілості та версію даних. Campaign total за 30 днів не можна непомітно порівнювати з одним ad за сім днів. Platform conversion, GA4 key event і CRM qualified outcome також не є одним показником лише тому, що мають схожу назву.

Правило доказу

Кожне число має відповідати на п’ять запитань: що виміряно, на якому рівні, за який період, яким джерелом і з яким обмеженням. Якщо однієї відповіді немає, статус поля — not_verified, а не нуль.

Evidence ledger до обчислень

Створіть реєстр доказів до того, як будувати висновки. Для кожного export або журналу запишіть source system, entity scope, extract time, owner, filename, row count, freshness, checksum або version ID та allowed use. Окремо позначте observed, derived, simulated і unavailable. Це не бюрократія: ledger допомагає побачити, що органічний export оновлено D+1, paid conversion ще дозріває, а CRM snapshot належить іншому cutoff.

Не переносіть у навчальний пакет usernames, email, message text або audience lists. Для community evidence достатньо неперсонального case ID, категорії, SLA, severity, action і result. Якщо screenshot потрібний для реального review, зберігайте його приватно, редагуйте персональні поля й додавайте access owner та retention date.

Reconciliation без чарівного «єдиного числа»

Починайте з таблиці зіставлення, а не з SUM. Рядок повинен містити metric concept, platform field, web field, downstream field, grain, window, status і пояснення різниці. Impressions не мають прямого аналога в CRM. Destination clicks можуть відрізнятися від sessions через redirects, consent, page load, bots і різні визначення. Platform conversions залежать від optimization event та attribution settings, тоді як CRM outcome може враховувати лише кваліфіковані заявки після ручного review.

Перевірте IDs, timezone, currency і період.
Узгодьте denominator і правила missing/zero.
Порахуйте контрольні totals у межах кожного джерела.
Поясніть очікувані розриви між джерелами.
Виділіть anomaly, яку треба дослідити, але не виправляйте дані для красивого звіту.

Reconciliation завершується не обов’язковим збігом, а відтворюваним поясненням: наприклад, «platform reports 18 attributed events, web layer has 12 consented sessions with the target event, CRM has 5 qualified cases; these layers are not additive».

Timeline пояснює, але не доводить причинність

Побудуйте campaign timeline: launch, creative swap, budget change, moderation incident, tracking interruption, landing update та data cutoff. Він допомагає знайти часові збіги й сформувати питання. Але формула «після зміни показник виріс, отже зміна спричинила ріст» лишається гіпотезою без контрольованого дизайну. Якщо одночасно змінено audience, creative і budget, чесний finding описує association і всі competing explanations.

Кожен finding оформлюйте як evidence → observation → interpretation → limitation → decision. Додайте owner, due date і verification method. Розділіть data-quality defect, delivery issue, audience/creative signal, community risk і business-capacity constraint: вони мають різні маршрути ескалації.

Практика: integrated report table

У synthetic pack перевірте evidence ledger, campaign timeline, metric reconciliation та community log. Потім створіть щонайменше п’ять findings: один підтверджений операційний факт, одну data-quality проблему, одну обмежену performance-інтерпретацію, один community/brand-safety guardrail і один висновок insufficient_evidence. Для кожного сформулюйте рішення continue/change/stop, але не називайте симуляцію реальним результатом.

Готовність до захисту

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

Методичні джерела

Сценарії, templates, synthetic case і питання — оригінальні матеріали SEOWORK. Platform definitions та reporting interface перевіряйте повторно перед роботою з реальними даними.