Модуль 8 · Урок 30
Deliverability, measurement і experiment log
Accepted не означає inbox, open не є надійним business outcome, а A/B test не виправляє зламану доставку. Побудуйте sender preflight, Postmaster monitoring, outcome measurement та experiment log із guardrails і stop rule.
Delivery pipeline
ESP «delivered» зазвичай означає accepted receiving server, а не гарантований inbox. Hard bounce — permanent failure; soft bounce, deferral або rate limit — тимчасовий сигнал із контрольованою retry policy. Block, spam complaint та unsubscribe потребують окремого monitoring і response.
Sender preflight
| Контроль | Питання |
|---|---|
| Identity | Чи точні From, domain, subject і sender purpose? |
| Authentication | Чи проходять SPF або DKIM, а для bulk — SPF, DKIM, DMARC та alignment? |
| Infrastructure | Чи є valid forward/reverse DNS, TLS, стабільні domain/IP streams? |
| Unsubscribe | Чи є видиме посилання, а для applicable bulk promotional mail — RFC 8058 one-click? |
| Volume | Чи зростає обсяг поступово та стабільно, без різких bursts? |
| Population | Чи eligible recipients, permissions і suppressions перевірені в момент send? |
Для Gmail bulk senders (близько 5,000+ повідомлень на день до personal Gmail) діють додаткові authentication, alignment і one-click вимоги. Google радить тримати user-reported spam нижче 0.1% і не досягати 0.3% або вище.
Postmaster і межі спостереження
Google Postmaster Tools показує Gmail-specific spam, domain/IP reputation, authentication, encryption та delivery errors. Дані не real-time, можуть бути відсутні при малому обсязі або через privacy thresholds і не описують інших mailbox providers.
Seed test — не population proof
Тестові адреси перевіряють render і базове проходження. Вони не гарантують inbox placement для всієї аудиторії, бо reputation, recipient history, content, volume і provider policy відрізняються.
Measurement contract
| Шар | Метрики | Рішення |
|---|---|---|
| Delivery health | Accepted, hard/soft bounce, blocks/deferrals | Pause, fix infrastructure або reduce rate |
| Trust | Complaints, unsubscribes, suppression latency | Stop/limit flow, inspect source і frequency |
| Interaction | Clicks, landing completion | Message/CTA/experience diagnosis |
| Outcome | Activation, qualified lead, renewal, revenue/margin | Continue, change або stop program |
Open rate може бути спотворений image blocking, privacy protection, proxy/caching і bot activity; Google окремо зазначає, що не відстежує open rate та не може перевірити third-party accuracy. Не робіть open primary business outcome.
Experiment log
Hypothesis + mechanism · eligible population · randomization unit · variants/control · primary metric · guardrails · sample/window rationale · exclusions · contamination risks · stop rule · owner.
- Спершу стабілізуйте permission, delivery й tracking; subject-line test на зламаній системі не відповість на business question.
- Розподіляйте на рівні, де treatment не змішується: зазвичай recipient/account, а не кожен send незалежно.
- Не вибирайте winner за першим випадковим підйомом; зафіксуйте window і uncertainty.
- Перевіряйте complaints, unsubscribe, bounce і downstream quality разом із primary metric.
- Запишіть result, alternative explanations, decision, owner і наступний review.
Практика уроку
- Пройдіть deliverability preflight для synthetic campaign.
- Складіть dashboard contract для delivery, trust, interaction і outcome.
- Визначте incident thresholds, pause owner і rollback.
- Спроєктуйте один експеримент із control, primary metric та guardrails.
- Напишіть readout template, який завершується continue/change/stop.
Офіційні джерела
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.