Чаму Amplitude патрабуе згоды

Браўзерны SDK Amplitude па змаўчанні і мабільныя SDK Amplitude робяць значна больш, чым запіс праглядаў старонак. Пры ініцыялізацыі яны ўсталёўваюць ідэнтыфікатар прылады ў першасным сховішчы, генеруюць ідэнтыфікатар сесіі, захопліваюць рэферэр, парсяць параметры UTM і ідэнтыфікатары клікаў з URL і пачынаюць ставіць у чаргу аўтаматычна захопленыя падзеі: прагляды старонак, клікі па элементах, узаемадзеянні з формамі, загрузкі файлаў і — у апошніх рэлізах — запісы сесій. Яны таксама ўзбагачаюць гэтыя падзеі геалакацыяй на аснове IP, данымі прылады на аснове user-agent і, калі наладжана, узбагачэннем трэціх бакоў ад партнёраў па даных.

Кожны з гэтых крокаў задзейнічае асобную прававую аснову згоды. Захоўванне ідэнтыфікатара прылады — гэта аперацыя захоўвання і доступу па артыкуле 5(3) Дырэктывы ePrivacy, якая патрабуе папярэдняй, свабодна дадзенай, канкрэтнай, інфармаванай і недвухсэнсоўнай згоды ў Еўрапейскай эканамічнай зоне, Вялікабрытаніі і любой юрысдыкцыі, якая імпартавала той жа стандарт. Захоп паводзінскіх падзей, прывязаных да гэтага ідэнтыфікатара, з'яўляецца апрацоўкай персанальных даных па GDPR. Узбагачэнне данымі трэціх бакоў уводзіць другія адносіны кантролера. CCPA і CPRA класіфікуюць тую ж апрацоўку як продаж ці перадачу, калі выдавец не мае належным чынам абмежаванага дагавора пастаўшчыка паслуг з Amplitude — які даступны, але толькі калі інтэграцыя наладжана на адключэнне рэкламных функцый.

Што Amplitude збірае да згоды — і што вы павінны падавіць

Самая распаўсюджаная памылка ўкаранення — разглядаць Amplitude як лёгкі інструмент аналітыкі, які можа працаваць побач з банерам cookie. Гэта немагчыма. Пры выкліку amplitude.init() па змаўчанні SDK на працягу першай адрысоўкі старонкі запіша як мінімум адзін cookie ці запіс лакальнага сховішча, адправіць выклік identify і пачне буферызацыю падзей. Нічога з гэтага не дапушчальна да таго, як карыстальнік сцвярджальна прыняў адпаведную катэгорыю згоды.

Адпаведная інтэграцыя павінна таму адкласці amplitude.init() да таго часу, пакуль CMP не падасць сігнал аб тым, што катэгорыя згоды на аналітыку прадастаўлена. SDK наогул не варта загружаць з тэга <script>, шлюзаванага па згодзе, які залежыць ад сігналу мэты 8 (аналітыка) ці мэты 1 (захоўванне і доступ) CMP, у залежнасці ад таго, які фрэймворк прадастаўляе CMP. Калі SDK павінен быць загружаны раней — напрыклад, бо ён убудаваны ў код прыкладання і не можа быць лена выняты — выклік ініцыялізацыі павінен перадаць defaultTracking: false і optOut: true, каб ніякія падзеі не выпускаліся да запісу згоды, а затым адкладзеная падзея opt-in павінна пераключыць гэтыя сцягі.

Cookie і сховішча, якія запісвае Amplitude

Браўзерны SDK 2.x запісвае адзін першасны cookie з імем AMP_{apiKey} па змаўчанні, з тэрмінам дзеяння адзін год, які змяшчае ідэнтыфікатар прылады і метаданыя сесіі. Больш старыя версіі таксама запісвалі amplitude_id_{apiKey}. Мабільныя SDK захоўваюць той жа ідэнтыфікатар унутры пясочнага сховішча прыкладання. Запіс сесіі дадае другі cookie, AMP_MKTG_{apiKey}, а партнёры па ўзбагачэнні Amplitude могуць усталёўваць дадатковыя староннія cookie, калі ўключаны модулі таргетынгу эксперыментаў ці аўдыторый. Усе яны неэсенцыяльны і патрабуюць згоды.

Супастаўленне Amplitude з фрэймворкамі згоды

Amplitude не рэалізуе натыўна Google Consent Mode v2, IAB TCF ці IAB Global Privacy Platform. Гэта не дэфект — Amplitude з'яўляецца першаснай аналітычнай платформай, а не ad-tech-пастаўшчыком — але гэта азначае, што адказнасць за інтэграцыю кладзецца на выдаўца. Шаблон, які працуе на практыцы, — разглядаць кожны модуль Amplitude як асобны шлюз згоды і прывязваць яго да канкрэтнага сігналу, які CMP ужо прадастаўляе.

• Асноўныя падзеі аналітыкі прывязваюцца да мэты аналітыкі. У тэрмінах TCF гэта часцей за ўсё мэта 8 (вымярэнне эфектыўнасці кантэнту) у спалучэнні з мэтай 1 (захоўванне і/ці доступ да інфармацыі). Для Google Consent Mode гэта супастаўляецца з analytics_storage.
• Запіс сесіі павінен знаходзіцца за больш строгім сігналам. Запіс захоплівае адрысаваны DOM, уключаючы значэнні формаў, калі яны відавочна не замаскіраваны, таму асобны opt-in preferences ці functional дарэчны, і запіс павінен быць адключаны па змаўчанні, нават калі аналітыка прадастаўлена.
• Аўдыторыі, кагорты і ўзбагачэнне трэціх бакоў прывязваюцца да маркетынгавай мэты. У тэрмінах TCF гэта мэта 7 (вымярэнне эфектыўнасці рэкламы) ці мэта 9 (прымяненне даследавання рынку). Для Google Consent Mode гэта супастаўляецца з ad_storage і ad_user_data.
• Эксперыменты — Amplitude Experiment можа працаваць з ананімным, эфемерным размеркаваннем на аснове законнага інтарэсу, але пастаяннае размеркаванне, прывязанае да ідэнтыфікатара карыстальніка, патрабуе той жа згоды, што і асноўная аналітыка.

Шаблон інтэграцыі, які працуе

Эталоннае ўкараненне, якое перажывае праверку рэгулятара, мае чатыры рухомыя часткі: CMP, які прадастаўляе падзею ў рэальным часе, калі карыстальнік мяняе згоду, адкладзены загрузчык SDK, які вымае Amplitude толькі пасля спрацоўвання гэтай падзеі для адпаведнай катэгорыі, абарону на ўзроўні сесіі, якая паважае opt-out, не губляючы папярэдні ананімны ідэнтыфікатар прылады карыстальніка там, дзе гэта дазваляе закон, і серверны мост для падзей, якія сапраўды патрабуюць збору незалежна ад згоды — такіх як тэлеметрыя бяспекі ці выяўленне махлярства — маршрутызаваных праз асобную канчатковую кропку з уласнай прававой асновай.

Вэб-укараненне

У вэбе самы чысты шаблон — прадаставіць стан згоды CMP праз аб'ект window.__cmp_consent ці стандартны зваротны выклік __tcfapi, затым мець невялікі скрыпт пачатковай загрузкі, які падпісваецца на змены згоды. Калі згода на аналітыку пераключаецца з false на true, пачатковая загрузка вымае SDK Amplitude з CDN, кіраванага CMP, выклікае amplitude.init(apiKey, undefined, { defaultTracking: true }) і прайгравае любыя падзеі, пастаўленыя ў чаргу ў памяці, пакуль згода чакалася. Калі згода пераключаецца назад на false, пачатковая загрузка выклікае amplitude.setOptOut(true), ачышчае cookie AMP_ праз сканчэнне document.cookie і выдаляе любы стан у памяці. Крытычна важна, пачатковая загрузка ніколі не павінна лена ініцыялізаваць Amplitude у тым жа патоку запытаў, што і адрысоўка банера — SDK павінен чакаць відавочнага прадастаўлення.

Мабільнае ўкараненне

На iOS эквівалент — трымаць фрэймворк Amplitude імпартаваным, але адкласці Amplitude.instance().initialize(apiKey: apiKey) да таго часу, пакуль унутрыпрыкладны паток згоды не верне станоўчы сігнал аналітыкі. Запыт ATT — гэта асобная праблема: ATT кіруе IDFA, тады як ідэнтыфікатар Amplitude — гэта ўласны UUID SDK, які захоўваецца ў пясочніцы прыкладання. Абодва патрабуюць згоды ў ЕЭЗ, але прававыя асновы і запыты розныя. На Android прымяняецца тая ж логіка з Amplitude.getInstance().initializeApolloClient() ці эквівалентам у залежнасці ад версіі SDK.

Серверны рэжым

Amplitude падтрымлівае серверны прыём праз HTTP V2 API. Серверныя падзеі не вызвалены ад згоды — прававая аснова ідзе за данымі, а не за транспартам — але серверны прыём дае выдаўцу поўны кантроль над тым, якія палі адпраўляюцца, што аблягчае выкананне частковай згоды. Распаўсюджаны шаблон — захопліваць мінімальны набор падзей толькі з эсенцыяльных на серверным баку на аснове законнага інтарэсу і ўзбагачаць гэтыя падзеі паводзінскімі дэталямі толькі пасля таго, як карыстальнік прадаставіў згоду на аналітыку на кліенце.

Валідацыя інтэграцыі

Крок валідацыі — той, які выдаўцы часцей за ўсё прапускаюць, а рэгулятары часцей за ўсё правяраюць. Правільна інтэграванае разгортванне Amplitude павінна прайсці чатыры праверкі. Па-першае, браўзер з паказаным банерам згоды, але без зробленага выбару, павінен вырабляць нуль запытаў да api.amplitude.com ці api.eu.amplitude.com і нуль cookie AMP_ у document.cookie. Па-другое, адхіленне катэгорыі аналітыкі павінна захоўваць гэты стан — ніякіх падзей, ніякіх cookie, ніякіх запісаў лакальнага сховішча з прэфіксам AMP_. Па-трэцяе, прыняцце аналітыкі павінна вырабляць адзін identify, за якім ідзе трафік падзей, і cookie AMP_ павінен з'явіцца з атрыбутам SameSite, узгодненым з палітыкай CMP выдаўца. Па-чацвёртае, адкліканне згоды пасля факта павінна неадкладна спыніць далейшыя падзеі і ачысціць захаваныя ідэнтыфікатары — адкладзеная ачыстка з'яўляецца знаходкай.

Аўдытарскі след мае значэнне асобна. Па кіраўніцтве EDPB па банерах cookie 2023 года і абноўленых прыярытэтах рабочай групы 2026 года рэгулятары чакаюць, што выдавец зможа даказаць для любой дадзенай падзеі ў праекце Amplitude, што карыстальнік, які яе згенераваў, даў сапраўдную згоду ў момант захопу. Гэта патрабуе, каб журнал згоды CMP можна было запытаць па ідэнтыфікатары прылады ці ідэнтыфікатары сесіі, а карысная нагрузка падзеі Amplitude несла поле версіі згоды, якое звязваецца назад з гэтым журналам. Захоўванне радка згоды як карыстальніцкай уласцівасці на кожнай падзеі — самы просты спосаб зрабіць гэту сувязь правяральнай.

Выбар правільнага рэгіёна і рэзідэнтнасці даных

Amplitude кіруе двума прадукцыйнымі рэгіёнамі: ЗША (api.amplitude.com) і ЕС (api.eu.amplitude.com). Для трафіку ЕЭЗ і Вялікабрытаніі рэгіён ЕС з'яўляецца правільным значэннем па змаўчанні — ён трымае даныя ўнутры ЕЭЗ і зніжае паверхню рызыкі перадачы, якую рашэнне Schrems II і Рамачнае пагадненне ЕС-ЗША аб прыватнасці даных зрабілі цэнтральнымі для любой праверкі аналітыкі. Пераключэнне рэгіёнаў не рэтраактыўна: існуючыя даныя застаюцца там, дзе яны былі ўпершыню прыняты. Для выдаўцоў, якія плануюць разгортванне CMP, таму варта пацвердзіць рэгіён перад маштабаваннем і варта задакументаваць выбар у апавяшчэнні аб прыватнасці, каб ланцужок прававой асновы быў чысты ад збору да захоўвання. Правільна выбраны рэгіён у спалучэнні з правільна шлюзаваным SDK і запытальным журналам згоды — гэта тое, што ператварае разгортванне Amplitude з рэгулятарнай рызыкі ў абаранімую частку аналітычнага стэка.