Англійська для сегмента CDP

Сегмент знаходиться між інженерією продукту, аналітикою і маркетинговими командами, що означає, що його словник повинен працювати у всіх трьох аудиторіях - розробник, який інструментує подію, і маркетолог, який налаштовує призначення, повинні говорити про одну і ту ж річ. Звичайно з такими термінами, як план відстеження, джерело і призначення англійською, запобігає багато “дані не збігаються” плутанини між командами.

Ключовий словник

** Джерело ** — джерело даних подій, що надходять до сегмента, наприклад, веб- сайт, мобільна програма або сервер, кожен з яких ідентифікується власним ключем запису.

• “Події з мобільної програми не з’ являються, оскільки ключ запису цього джерела було змінено минулого тижня, а програма все ще має старий ключ.” *

** Призначення** — будь- який інструмент Сегмент пересилає дані подій до, наприклад, платформи аналітики, рекламної мережі або сховища даних, які налаштовано незалежно від джерела. “Ми додали нове місце призначення для рекламної платформи маркетингової команди, але нам потрібно перевірити, чи отримує вона лише події, які мають чинну згоду.”

** План стеження ** — формальне позначення подій, які слід надіслати, з якими властивостями і типами, що використовується для перевірки вхідних даних за узгодженою схемою.

• “Ця подія порушує план відстеження, оскільки price надсилається як рядок замість числа, отже, вона не пройшла перевірку перед тим, як досягти будь- якого місця призначення.” *

** Виклик ідентифікації ** — виклик API Segment, який пов’ язує користувача з набором характеристик, зв’ язуючи анонімну і відому поведінку разом під одним профільом користувача. “Події перетворення не пов’ язані з користувачами, які увійшли до системи, оскільки ми не отримуємо виклику ідентифікації відразу після входу — зараз кожен сеанс виглядає анонімним.”

** Порушення протоколів ** — подія або властивість, яка не відповідає визначеній схемі плану стеження, що може бути налаштовано у сегменті для блокування, попередження або дозволу з прапорцем.

• “Ми спостерігаємо зростання порушень протоколів з останнього випуску — хтось перейменував властивість події без оновлення плану відстеження.” *

Звичайні фрази

• «З якого джерела ця подія насправді походить — з веб-апарата або з мобільного пристрою?»
• Чи це призначення отримує подію взагалі, або це проблема з картографуванням вниз по течії?»
• Це виглядає як порушення плану стеження — чи можете ви перевірити типи власності?»
• Чи ми викликали виклик ідентифікації до цієї події, або користувач все ще анонімний?
• «Ми повинні розглядати це як порушення протоколів і блокувати його, поки схема не буде виправлена»

Приклади висловлювань

Зневадження відсутніх даних аналітики:

• « Подія правильно прибуває до джерела, але її не показано на панелі призначення — я думаю, що призначення ще не розпізнало цю нову назву властивості. » *

Пояснення зміни схеми: “Ми оновили план відстеження, щоб зробити plan_type обов’ язковим для цієї події, тому будь- який клієнт, який все ще надсилає її без цієї властивості, тепер буде показано як порушення протоколів.”

Прийом нового інженера:

• “Завжди викликати ідентифікацію відразу після входу до системи, перед будь- якими іншими відстежуваними подіями — інакше ці події залишатимуться анонімними і ніколи не будуть об’ єднані з повною історією користувача.” *

Професійні поради

• Вкажіть точне ** джерело ** і ** призначення **, пов’ язані зі звітуванням про невідповідність даних — « дані неправильні » не допоможе, але « події з цього джерела не досягають цього призначення » дасть комусь конкретне місце, з якого можна почати.
• Перевірте ** план стеження ** перед тим, як припустити ваду програми, коли аналітичні дані виглядають неправильно — тихо перейменована властивість є однією з найпоширеніших причин « відсутності » даних, які було насправді надіслано, а не просто відхилено.
• Згадувати, чи відбувалося виклик identify перед іншими подіями під час зневадження прогалин у приписуванні — непов’ язані анонімні події є частою, легкою до ігнорування причиною недоліку перетворень.
• Розглядати ** порушення протоколів ** як сигнал для виправлення джерела правди, а не просто приглушувати попередження — обхід перевірки без повідомлення, зазвичай, лише переносить ту ж саму плутанину на тих, хто пізніше створить звіт.

Практичні вправи

1. Поясніть, в одному реченні, різницю між джерелом і призначенням у моделі Segment.
2. Описує, чому відсутній виклик ідентифікації може призвести до того, що події перетворення будуть виглядати як від’ єднані від відомого користувача.
3. Напишіть два речення, у яких ви поясните співробітнику команди, чому подія показується як порушення плану стеження, і що слід змінити, щоб виправити ситуацію.

Назва походить від фразеології: спільне слово в окремих мовах

Будьмо чесними - навіть досвідчені розробники іноді натякають на точну мову, необхідну для ефективного обговорення технічних деталей, особливо при співпраці між різними командами або спілкуванні з зацікавленими сторонами. Фокус сегменту на даних в реальному часі і гранулярному відстеженні означає, що розмови можуть швидко стати щільними з термінологією. Для не-рідних англомовних носіїв, розуміння тонких відмінностей у фразування може бути вирішальним для ясності і уникнення непорозумінь. Це не просто знати слова, але як вони використовуються для передачі намірів і впливу.

Часта проблема виникає під час перегляду коду. Уявіть сценарій, в якому ви переглядаєте PR, який додає нове джерело даних, під’єднане до Google Analytics. Коментар від старшого інженера може бути таким: « Це добре, але чи можете ви пояснити конвенцію назв подій? Нам потрібна послідовність у всіх наших джерелах.” Просто сказати “роз’яснити” недостатньо. Основний нюанс тут полягає у тому, що ви просите про * докладне пояснення * і підкреслюєте важливість дотримання встановлених стандартів — запит, який звучить більш професійно і практично, ніж нечітка інструкція. Аналогічно, під час обговорення Slack щодо якості даних, ви можете почути, як хтось каже: « Чи правильно відстежується ця подія? Схоже, що відсутні деякі ключові виміри. » Це не просто вказівка на помилку; це запит на * перевірку * налаштувань стеження і запит на конкретну інформацію про те, що відсутнє.

Іншою поширеною ситуацією є написання описів PR. Хороший опис повинен бути коротким і інформативним, чітко визначаючи очікування. Замість простого «Додано джерело GA», кращим підходом було б: «Впроваджено Google Analytics як нове джерело даних, використовуючи кінцеву точку API event_tracking. За допомогою цього пункту можна передавати події користувача (перегляди сторінок, клацання) з відповідними параметрами, такими як адреса URL сторінки і тип пристрою. Потрібно провести подальші дослідження, щоб забезпечити точне відображення подій за існуючими моделями сегментів — будь ласка, ознайомтеся з документацією у [посилання на документацію] для отримання пояснень. » Зауважте, що ця версія містить більше відомостей про те, як * було * реалізовано цей метод, які дані він передає, і звертає увагу на ресурси підтримки. Це демонструє активний підхід і зменшує потребу в подальших питаннях.

Нарешті, пам’ ятайте, що точність є ключем при обговоренні метрики. Замість того, щоб сказати «це збільшило конверсії», краще сказати: «Ми спостерігали статистично значуще збільшення коефіцієнта конверсії (p < 0, 05) після впровадження цієї нової події відстеження». Цей рівень деталізації — кількісне вираження зміни і надання контексту — додає ваги вашим спостереженням і полегшує прийняття рішень на основі інформації.

# Example Segment CLI command for querying data source status
segment query --data-source google_analytics

Після виконання цієї команди буде повернуто об’ єкт JSON, у якому міститимуться відомості щодо з’ єднання джерела даних Google Analytics, стану відстеження подій і всіх можливих проблем, які потребують уваги. Зрозуміти цей вихід і бути в змозі чітко сформулювати свої висновки - це фундамент ефективного співробітництва в середовищі Segment.