Коли я додавала аналітику поширень, спочатку сама назва метрики могла підштовхнути до занадто простого рішення: є Share, отже можна просто рахувати все, що пов’язане з поширеним посиланням, в одному місці.
Але насправді тут є дві різні події.
Перша відбувається, коли користувач натискає Share або Copy Link. Друга відбувається пізніше, якщо хтось відкриває поширене посилання.
Ці події можуть бути пов’язані причинно, але вони не є однією й тією самою дією.
Перша подія: користувач натиснув Share
Time: 10:15 User A | +-- відкриває статтю | +-- натискає «Поділитися» | +-- обирає «Копіювати посилання» | vДію «Поділитися» зафіксованоЦе подія взаємодії з інтерфейсом.
Ми знаємо, який контент поширювали, яким способом це зробили і в який момент.
Але ми ще нічого не знаємо про результат. Посилання могли скопіювати й нікому не надіслати. Могли надіслати в приватний чат. Могли надіслати десятьом людям.
Тому Share action сама по собі не є visit.
Друга подія: інша людина відкрила shared link
Time: 10:47 User B | +-- отримує спільне посилання | +-- відкриває його | vВідвідування за спільним посиланням зафіксованоЦя подія відбувається пізніше і часто на іншому пристрої.
Тут ми вже вимірюємо результат: поширення привело когось на сайт.
Якщо посилання містить достатньо інформації для визначення джерела переходу, відвідування можна пов’язати з конкретним способом поширення або джерелом трафіку. Але це все одно окрема подія, а не продовження початкового запису про поширення.
Одна подія є причиною, інша - результатом
Дія «поділитися» | | може призвести до vПерехід за поширеним посиланням But: Але: 1 дія «поділитися»може спричинити0, 1 або багато переходівСаме тут найпростіше порушити точність аналітики одним лічильником.
Якщо збільшувати поширення і під час натискання кнопки поширення, і під час переходу за поширеним посиланням, одна метрика почне відображати дві різні дії.
Після цього вже неможливо буде визначити, скільки разів користувачі насправді поширили матеріал і скільки відвідувань принесли ці поширення.
Одне поширення може не привести жодного відвідувача на сайт
Copy Link підтверджує лише те, що користувач отримав посилання в clipboard.
Він може закрити вкладку, передумати або використати URL пізніше.
Тому метрика Share потрібна сама по собі: вона показує намір поширити контент, навіть якщо outcome ще не настав.
Одне поширення може привести на сайт багато відвідувачів.
1 Дія «Поділитися» поділено в груповий чат | +-- Відвідування A +-- Відвідування B +-- Відвідування C +-- Відвідування DЦе ще одна причина не зводити події до одного числа.
Один share в груповий чат або публічний канал потенційно створює багато переходів.
Якщо система передбачає, що кожному поширенню відповідає рівно одне відвідування, вона неправильно відображає реальну поведінку користувачів.
Ці події належать різним людям
Дія поширення належить користувачу, який поширює матеріал. Перехід за поширеним посиланням належить користувачу, який його відкриває.
Навіть якщо обидва користувачі авторизовані, це різні учасники подій. Якщо ж вони неавторизовані, система може взагалі не знати їхніх постійних ідентифікаторів.
Тому я не намагаюся зберігати все в одному записі про поширення, який згодом оновлюється внаслідок дій іншої людини.
У коді я теж розділяю ці події
final readonly class ShareRecorded{ public function __construct( public int $contentId, public string $channel, ) { }} final readonly class SharedLinkVisited{ public function __construct( public int $contentId, public ?string $source, ) { }Назва події тут дуже важлива.
ShareRecorded не обіцяє visit. SharedLinkVisited не говорить, що ми бачили сам Share action.
Коли ці поняття розділені в коді, їх складніше випадково змішати в агрегації або dashboard.
У dashboard це теж мають бути різні метрики
SHARES128 ATTRIBUTED VISITS46 VISITS PER SHARE0.36SHARES показує, скільки разів користувачі виконали share action.
ATTRIBUTED VISITS показує, скільки переходів вдалося пов’язати з поширеними посиланнями.
VISITS PER SHARE уже є похідною метрикою. Вона допомагає оцінити, наскільки дії з поширення матеріалів справді приводять нових відвідувачів на сайт.
Для переходу за поширеним посиланням потрібно визначити джерело відвідування, а для самої дії поширення - ні.
Дія поширення відбувається безпосередньо в нашому інтерфейсі, тому ми одразу знаємо, звідки вона походить.
З відвідуванням складніше. Запит надходить пізніше, і система повинна мати спосіб визначити, що користувач перейшов за посиланням, створеним під час поширення матеріалу.
Для цього можна використовувати спеціальний параметр у посиланні, ідентифікатор поширення або інший спосіб визначення джерела переходу.
Конкретна реалізація може відрізнятися, але принцип залишається незмінним: дія поширення та перехід за посиланням - це дві окремі події, які можна пов’язати між собою.
Не кожне відвідування можна достовірно пов’язати з конкретною дією поширення
Посилання можуть переслати іншій людині, видалити з нього додаткові параметри, вставити в інший сервіс або відкрити через застосунок, який змінює URL.
Тому я не намагаюся вважати кожне пряме відвідування результатом поширення лише на підставі припущення.
Якщо немає достатніх даних, які підтверджують джерело переходу, краще залишити відвідування без визначеного джерела, ніж штучно завищувати ефективність поширень в аналітиці.
Правила усунення повторних подій для поширень і відвідувань також можуть відрізнятися
Для дії поширення можна окремо визначити, чи враховувати повторні натискання кнопки одним користувачем протягом короткого проміжку часу.
Для відвідувань правила інші: одна людина може кілька разів перейти за поширеним посиланням, а кілька різних людей можуть відкрити той самий URL.
Якщо застосувати до обох типів подій одне універсальне правило усунення повторів, це майже напевно призведе до спотворення хоча б одного з показників аналітики.
Разом ці події утворюють послідовність дій, за якою можна оцінити ефективність поширення матеріалів, а не просто один спільний лічильник.
Перегляд статті | vДія «Поділитися» | vПерехід за поширеним посиланням | vПодальша взаємодіяКоли події розділені, можна отримувати значно корисніші аналітичні дані.
Які матеріали користувачі поширюють найчастіше? Через які канали поширення приходить найбільше відвідувачів? Скільки з них після переходу читають інші сторінки сайту? Які матеріали часто поширюють, але вони майже не приводять нових відвідувачів?
Один загальний лічильник не дозволяє відповісти на жодне з цих запитань.
Що відбувається, якщо змішати причину та результат
SHARES перестає відображати кількість реальних дій поширення.
Неможливо визначити, яка частка поширень приводить відвідувачів на сайт.
Одне популярне поширене посилання може штучно збільшити кількість поширень на десятки.
Правила усунення повторних подій починають суперечити одне одному.
Неможливо відрізнити намір користувача поширити матеріал від фактичного результату цієї дії.
Аналітика починає показувати вищу активність, ніж є насправді.
Моя проста модель для таких подій
Дія: поширення content_idканалконтекст суб'єкта діїoccurred_at Перехід за поширеним посиланням content_idджерело поширенняконтекст відвідувачаoccurred_atЯ не вважаю, що обидві події обов’язково потрібно зберігати в одній таблиці або що вони повинні мати однакову структуру даних.
Важливіше інше: кожен запис повинен мати чітке й однозначне значення.
Якщо кожна подія відповідає на одне конкретне запитання, її простіше перевіряти тестами, використовувати для підрахунку показників і відображати в аналітиці.
Тести теж стають простішими, коли події розділені
public function test_copy_link_records_share_action(): void{ // user performs Copy Link $this->assertSame( 1, $this->sharesFor($post), );} public function test_shared_link_visit_does_not_increment_shares(): void{ // another visitor opens attributed link $this->assertSame( 1,Одна метрика повинна мати одне значення
Найкорисніший висновок для мене стосується не лише аналітики поширень.
Коли одна дія може згодом призвести до іншого результату, я намагаюся не об’єднувати їх в одну подію лише тому, що між ними існує причинно-наслідковий зв’язок.
Поширення матеріалу - це причина. Перехід за поширеним посиланням - це можливий результат. Ці події пов’язані між собою, але вимірювати їх потрібно окремо.
Якщо один counter одночасно означає "користувач поділився" і "хтось прийшов за посиланням", це вже не одна метрика, а дві змішані історії.
