Што насамрэч робіць Segment

SDK Segment (загружаемы з cdn.segment.com/analytics.js) ініцыялізуе глабальны аб'ект analytics і ідэнтыфікуе наведвальнікаў з дапамогай належнага Segment cookie пад назвай ajs_anonymous_id. Код праграмы выклікае analytics.identify(), analytics.track(), analytics.page() і analytics.group(), і SDK перасылае кожны выклік на канчатковы пункт прыёму Segment. Адтуль Segment разыходзіць падзею — у рэальным часе або праз пакет — да любых пунктаў прызначэння, уключаных на крыніцы: Google Analytics, Facebook Pixel, Customer.io, Iterable, Amplitude, Mixpanel, Snowflake, BigQuery і дзясяткам іншых.

Кожная перасылка ў ніжэйстаячы пункт прызначэння — гэта асобная дзейнасць па апрацоўцы з пункту гледжання GDPR. Прававая аснова для адпраўкі падзеі ў Google Analytics не тая ж, што для адпраўкі той жа падзеі ў Customer.io, не тая ж, што для запісу той жа падзеі ў сховішча Snowflake. Банер згоды, які запісвае адзінае «Я прымаю маркетынг», не можа законна аўтарызаваць усё гэта сам па сабе, калі толькі катэгарызацыя пунктаў прызначэння не адпавядае катэгарызацыі згоды.

Натыўныя прымітывы згоды Segment

Segment уклаў шмат сродкаў у прымітывы кіравання згодай за апошнія два гады. Па стане на 2026 год платформа прадастаўляе тры значныя паверхні для забеспячэння згоды.

Consent Management (раней Consent Stamping)

Функцыя Consent Management дазваляе прымацоўваць карысную нагрузку згоды да кожнай падзеі, якую прымае Segment. Карысная нагрузка запісвае, якія катэгорыі апрацоўкі карыстальнік прыняў — звычайна радок IAB TCF v2.3, радок GPP або карыстальніцкую катэгарызацыю Segment. Ніжэйстаячыя пункты прызначэння могуць быць наладжаны на перасылку або блакіроўку на аснове стану згоды на кожнай падзеі.

Фільтры пунктаў прызначэння з гейтаваннем згоды

Фільтры пунктаў прызначэння дазваляюць напісаць невялікі выраз JavaScript або Lua, які выконваецца на кожнай падзеі да яе перасылкі ў канкрэтны пункт прызначэння. Фільтр можа праверыць карысную нагрузку згоды і закараціць перасылку, калі адпаведная катэгорыя не была прадастаўлена. Гэта правільны прымітыў для дэталёвага забеспячэння згоды па кожным пункце прызначэння.

Налада integrations на ўзроўні крыніцы

Для больш грубага кантролю аб'ект integrations на ўзроўні крыніцы можа цалкам адключаць пункты прызначэння на аснове кожнай падзеі: analytics.track(event, properties, { integrations: { "All": false, "Segment.io": true } }). Гэта карысна для выпадку «усё або нічога», але дрэнна апрацоўвае гранулярнасць на ўзроўні катэгорый.

Пакрокавая інтэграцыя CMP

Надзейная архітэктура — супаставіць рашэнні катэгорый CMP з катэгарызацыяй пунктаў прызначэння Segment, прымацаваць карысную нагрузку згоды да кожнай падзеі і выкарыстоўваць фільтры пунктаў прызначэння для забеспячэння гейтавання па кожным пункце прызначэння.

1. Катэгарызуйце пункты прызначэння

Прайдзіце спіс уключаных пунктаў прызначэння ў вашым працоўным прасторы Segment і прызначце кожнаму катэгорыю CMP. Пункты прызначэння, такія як Google Analytics, Mixpanel і Amplitude, звычайна аналітыка. Пункты прызначэння, такія як Facebook Pixel, TikTok і Pinterest, звычайна маркетынг. Пункты прызначэння, такія як Snowflake або BigQuery (ваша ўласнае сховішча), звычайна неабходныя або функцыянальныя — але толькі калі аналітыка, апрацоўваемая ніжэй сховішча, таксама катэгарызавана правільна. Задакументуйце гэта супастаўленне дзесьці правяральным; абарона аўдыту абапіраецца на яго.

2. Адкладзіце ініцыялізацыю SDK да захопу рашэння пра згоду

SDK Segment можа быць наладжаны не адпраўляць падзеі, пакуль не выкліканы analytics.load(). Адкладзіце выклік load, пакуль CMP не захапіла рашэнне карыстальніка, каб ніякія падзеі не спрацоўвалі да згоды. У якасці альтэрнатывы выкарыстоўвайце патэрн чаргі analytics.ready() з гейтаваннем стану згоды ў саміх апрацоўшчыках падзей.

3. Прымацуйце карысную нагрузку згоды да кожнай падзеі

Наладзьце функцыю Consent Management, каб штампаваць радок IAB TC, радок GPP або вашу карыстальніцкую катэгарызацыю на кожную прынятую падзею. Штамп падарожнічае з падзеяй праз канвеер Segment і даступны фільтрам пунктаў прызначэння.

4. Напішыце фільтры пунктаў прызначэння для забеспячэння на ўзроўні катэгорый

Для кожнага пункта прызначэння напішыце фільтр, які правярае карысную нагрузку згоды супраць катэгорыі, якую патрабуе гэты пункт прызначэння. Калі карыстальнік прыняў маркетынг, але адхіліў аналітыку, пункты прызначэння катэгорыі маркетынг атрымліваюць падзею, а пункты прызначэння катэгорыі аналітыка моўчкі адкідаюцца. Логіка фільтра звычайна чытае з event.context.consent.categoryPreferences або эквівалентнага шляху ў схеме карыснай нагрузкі згоды.

5. Распаўсюджвайце адклікі

Калі карыстальнік адклікае згоду, павінны адбыцца дзве рэчы: SDK спыняе адпраўляць новыя падзеі пад адкліканымі катэгорыямі (апрацоўваецца пераключальнікам integrations на ўзроўні крыніцы), і існуючы профіль карыстальніка ў ніжэйстаячых пунктах прызначэння трэба абнавіць або выдаліць. Privacy API Segment падтрымлівае як запыты на выдаленне, так і сцягі падаўлення; наладзьце CMP на выклік адпаведнага канчатковага пункта Privacy API пры адкліканні.

Распаўсюджаныя пасткі

Чатыры памылкі інтэграцыі складаюць большасць высноў аўдыту па разгортваннях Segment.

Разгляд Segment як адзінага трэкера

Самы распаўсюджаны дэфект: гейтаванне Segment пад адзінай катэгорыяй (звычайна аналітыка) і дапушчэнне, што гэта задавальняе ўсё ніжэйстаячае. Гэта не так. Калі Facebook Pixel уключаны як пункт прызначэння, падзея, перасылаемая ў Facebook, патрабуе згоды катэгорыі маркетынг, а не аналітыкі. Катэгарызацыя па кожным пункце прызначэння абавязковая.

Забыванне пра пункт прызначэння сховішча

Многія каманды ўключаюць Snowflake або BigQuery як пункт прызначэння Segment і разглядаюць сховішча як вызваленае, таму што «гэта ўнутраная інфраструктура». Само сховішча можа быць унутраным, але наступная апрацоўка — BI-дашборды, мадэляванне падобных аўдыторый, сегментацыя кліентаў — сілкуе маркетынгавыя і аналітычныя функцыі. Катэгарызацыя згоды сховішча павінна адлюстроўваць найбольш дазваляючае выкарыстанне, у якое ў канчатковым выніку трапляюць даныя сховішча.

Серверныя крыніцы без кантэксту згоды

Segment падтрымлівае серверныя крыніцы (ваш бэкенд, які выклікае Segment напрамую). Падзеі з гэтых крыніц не ўспадкоўваюць аўтаматычна браўзернае стан згоды. Праграма павінна шукаць стан згоды карыстальніка падчас эмісіі падзеі і прымацоўваць яго да выкліку. Без гэтага серверныя падзеі цалкам абыходзяць CMP.

Ігнараванне міжкрыніцовага зліцця ідэнтычнасці

Разрашэнне ідэнтычнасці Segment злівае ананімныя і ідэнтыфікаваныя профілі, і яно можа рабіць гэта праз вэб-, мабільныя і серверныя крыніцы. Калі стан згоды адрозніваецца паміж гэтымі паверхнямі, зліты профіль успадкоўвае найбольш дазваляючую інтэрпрэтацыю па змаўчанні. Наладзьце разрашэнне ідэнтычнасці на выкарыстанне найбольш абмежавальнага стану згоды сярод злітых ідэнтычнасцяў, а не найбольш дазваляючага.

Кантрольны спіс аўдыту

Шэсць канкрэтных пытанняў для любога разгортвання Segment, якое закранае трафік ЕС, Вялікабрытаніі або Каліфорніі.

• Ці задакументавана катэгарызацыя пунктаў прызначэння? Для кожнага ўключанага пункта прызначэння ці ёсць пісьмовы запіс пра тое, якая катэгорыя CMP яго гейтуе?
• Ці чакае SDK згоды? Адкрыйце старонку ў прыватным акне і пацвердзіце, што ніякія выклікі analytics.track не спрацоўваюць у api.segment.io да прыняцця банера.
• Ці штампуюцца карысныя нагрузкі згоды на кожнай падзеі? Праверце ўзор прынятых падзей у адладчыку Segment і пацвердзіце, што карысная нагрузка згоды прысутнічае і поўная.
• Ці выконваюць фільтры пунктаў прызначэння катэгорыі? Пацвердзіце, што адключэнне катэгорыі ў CMP прыводзіць да таго, што падзеі не перасылаюцца ў пункты прызначэння гэтай катэгорыі.
• Ці нясуць серверныя крыніцы згоду? Пацвердзіце, што серверныя выклікі шукаюць і прымацоўваюць цяперашні стан згоды карыстальніка падчас эмісіі.
• Ці спрацоўвае Privacy API пры адкліканні? Пацвердзіце, што адклікі, якія запускаюцца CMP, выклікаюць API падаўлення або выдалення Segment, а не толькі лакальны opt-out SDK.

Дзе Segment упісваецца ў стэк, арыентаваны на згоду

CDP займаюць найбольш рычажную пазіцыю ў архітэктуры прыватнасці: адзінае рашэнне на банеры CMP павінна распаўсюдзіцца да дзясяткаў ніжэйстаячых пунктаў прызначэння, кожны са сваёй прававой пазіцыяй. Правільная архітэктура разглядае CMP як крыніцу праўды для катэгарыяльных пераваг карыстальніка, прымацоўвае гэту праўду да кожнай падзеі, якую прымае Segment, і выкарыстоўвае прымітывы фільтраў пунктаў прызначэння Segment для забеспячэння гейтавання на ўзроўні катэгорый на слоі маршрутызацыі, а не на кожным асобным пункце прызначэння. Зробленая правільна, інжынерная праца маштабуецца лінейна з колькасцю пунктаў прызначэння — даданне новага пункта прызначэння — гэта рашэнне пра катэгарызацыю і правіла фільтра, а не свежая інтэграцыя. Зроблены няправільна, CDP становіцца множнікам прыватнасці, перасылаючы парушаючыя згоду падзеі доўгаму хвасту партнёраў хутчэй, чым любы ручны аўдыт можа дагнаць.