Bakit nangangailangan ng pahintulot ang Amplitude

Ang default na Amplitude Browser SDK at ang Amplitude mobile SDK ay gumagawa ng higit pa sa pagtatala ng mga page view. Sa pagsisimula, nagtatakda sila ng device identifier sa first-party na storage, bumubuo ng session identifier, kumukuha ng referrer, nag-parse ng UTM at click identifier mula sa URL, at nagsisimulang mag-queue ng mga autocaptured na event: mga page view, element click, form interaction, file download, at — sa mga pinakabagong release — session replay. Ina-enrich din nila ang mga event na iyon ng IP-derived na geolocation, user-agent-derived na device data, at, kung naka-configure, third-party na enrichment mula sa mga data partner.

Ang bawat isa sa mga hakbang na iyon ay nakikisangkot sa isang hiwalay na legal na batayan ng pahintulot. Ang pag-iimbak ng isang device identifier ay isang operasyon ng pag-iimbak-at-pag-access sa ilalim ng Artikulo 5(3) ng ePrivacy Directive, na nangangailangan ng nauna, malaya, tukoy, may kaalaman, at walang kalabuan na pahintulot sa European Economic Area, United Kingdom, at anumang hurisdiksyon na nag-import ng parehong pamantayan. Ang pagkuha ng mga behavioral event na nakatali sa identifier na iyon ay pagpoproseso ng personal na data sa ilalim ng GDPR. Ang pagpapayaman ng third-party na data ay nagpapakilala ng pangalawang relasyon ng controller. Inuuri ng CCPA at CPRA ang parehong pagpoproseso bilang isang pagbebenta o pagbabahagi maliban kung ang publisher ay may wastong limitadong kontrata ng service-provider sa Amplitude — na available, ngunit kung ang integrasyon ay na-configure upang i-disable ang mga advertising feature lamang.

Ano ang kinokolekta ng Amplitude bago ang pahintulot — at ano ang kailangang pigilan

Ang pinakakaraniwang pagkakamali sa implementasyon ay ang pagtrato sa Amplitude bilang isang magaang na analytics tool na maaaring tumakbo kasabay ng cookie banner. Hindi ito maaari. Sa isang default na tawag na amplitude.init(), ang SDK ay, sa unang paint ng page, susulat ng hindi bababa sa isang cookie o local storage entry, magpadala ng identify na tawag, at magsisimulang mag-buffer ng mga event. Wala sa mga ito ang pinahintulutan bago tanggapin ng isang user ang may kaugnayan na kategorya ng pahintulot.

Ang isang naaayon na integrasyon ay dapat samakatuwid na antalahin ang amplitude.init() hanggang sa senyales ng CMP na ang kategorya ng pahintulot ng analytics ay naibigay na. Ang SDK ay hindi dapat i-load mula sa isang pahintulot na gated na <script> tag na nakasalalay sa senyales ng layunin 8 (analytics) o layunin 1 (imbakan at access) ng CMP, depende sa kung anong balangkas ang ibinubunyag ng CMP. Kung ang SDK ay kailangang i-load nang mas maaga — halimbawa dahil ito ay nakabalot sa application code at hindi maaaring i-lazily fetch — ang tawag sa pagsisimula ay dapat magpasa ng defaultTracking: false at optOut: true upang walang event ang mailabas hanggang maitala ang pahintulot, at pagkatapos ang isang deferred opt-in na event ay dapat mag-flip ng mga flag na iyon.

Ang mga cookie at storage na sinusulatan ng Amplitude

Ang Browser SDK 2.x ay sumusulat ng isang solong first-party na cookie na pinangalanang AMP_{apiKey} bilang default, may isang taon na expiry, naglalaman ng device identifier at session metadata. Ang mga mas lumang bersyon ay nagsulat din ng amplitude_id_{apiKey}. Iniimbak ng mga mobile SDK ang parehong identifier sa loob ng sandboxed na storage ng application. Nagdadagdag ang session replay ng pangalawang cookie, AMP_MKTG_{apiKey}, at ang mga enrichment partner ng Amplitude ay maaaring magtakda ng karagdagang third-party na cookie kung ang mga module ng experiment-targeting o audiences ay pinagana. Lahat ng ito ay hindi mahalaga at nangangailangan ng pahintulot.

Pag-map ng Amplitude sa mga balangkas ng pahintulot

Ang Amplitude ay hindi natively nagpapatupad ng Google Consent Mode v2, IAB TCF, o IAB Global Privacy Platform. Hindi ito isang depekto — ang Amplitude ay isang first-party analytics platform, hindi isang ad-tech vendor — ngunit nangangahulugan ito na ang responsibilidad sa integrasyon ay nasa publisher. Ang pattern na gumagana sa practice ay ang pagtrato sa bawat Amplitude module bilang isang hiwalay na consent gate at iugnay ito sa isang tukoy na senyales na ibinubunyag na ng CMP.

• Mga pangunahing analytics event ay nagbubuklod sa layunin ng analytics. Sa mga tuntunin ng TCF ito ay kadalasang layunin 8 (measure content performance) na pinagsama sa layunin 1 (mag-imbak at/o ma-access ang impormasyon). Para sa Google Consent Mode ito ay nagma-map sa analytics_storage.
• Ang session replay ay dapat nasa likod ng mas mahigpit na senyales. Ang replay ay kumukuha ng rendered DOM, kasama ang mga form value maliban kung malinaw na na-mask, kaya ang isang hiwalay na preferences o functional opt-in ay angkop, at ang replay ay dapat default sa off kahit na ang analytics ay naibigay.
• Mga audience, cohort, at third-party enrichment ay nagbubuklod sa layunin ng marketing. Sa mga tuntunin ng TCF ito ay layunin 7 (measure ad performance) o layunin 9 (apply market research). Para sa Google Consent Mode ito ay nagma-map sa ad_storage at ad_user_data.
• Eksperimentasyon — Ang Amplitude Experiment ay maaaring tumakbo na may anonymous, ephemeral allocation sa ilalim ng legitimate-interest basis, ngunit ang persistent allocation na nakatali sa isang user identifier ay nangangailangan ng parehong pahintulot gaya ng core analytics.

Ang pattern ng integrasyon na gumagana

Ang reference implementation na nakakaligtas sa review ng regulator ay may apat na bahagi: isang CMP na naglalantad ng real-time na event kapag binago ng user ang pahintulot, isang deferred SDK loader na kumukuha lamang ng Amplitude pagkatapos na maputok ang event na iyon para sa may kaugnayan na kategorya, isang session-level na guard na gumagalang sa opt-out nang hindi nawawala ang naunang anonymous device identifier ng user kung saan pinapayagan ng batas, at isang server-side bridge para sa mga event na tunay na nangangailangan ng koleksyon anuman ang pahintulot — tulad ng security telemetry o fraud detection — na iniruta sa pamamagitan ng isang hiwalay na endpoint na may sariling legal na batayan.

Implementasyon ng web

Sa web, ang pinakamalinis na pattern ay ang ilantad ang consent state ng CMP sa pamamagitan ng isang window.__cmp_consent object o ang standard na __tcfapi callback, pagkatapos ay magkaroon ng isang maliit na bootstrap script na mag-subscribe sa mga pagbabago ng pahintulot. Kapag ang analytics consent ay lumipat mula sa false patungong true, ang bootstrap ay kukuha ng Amplitude SDK mula sa CMP-managed CDN, tatawag ng amplitude.init(apiKey, undefined, { defaultTracking: true }), at mag-replay ng anumang mga event na naka-queue sa memory habang naghihintay ang pahintulot. Kapag bumalik ang pahintulot sa false, tatawag ang bootstrap ng amplitude.setOptOut(true), mag-clear ng AMP_ cookie sa pamamagitan ng pag-expire ng document.cookie, at mag-aalis ng anumang in-memory state. Kritikal, ang bootstrap ay hindi dapat i-lazily initialize ang Amplitude sa parehong request flow gaya ng banner render — ang SDK ay dapat maghintay ng isang tahasang grant.

Implementasyon ng mobile

Sa iOS ang katumbas ay ang panatilihing na-import ang Amplitude framework ngunit antalahin ang Amplitude.instance().initialize(apiKey: apiKey) hanggang sa ang in-app consent flow ay nagbalik ng positibong analytics signal. Ang ATT prompt ay isang hiwalay na alalahanin: ang ATT ay namamahala ng IDFA, habang ang identifier ng Amplitude ay ang sariling UUID ng SDK na nakaimbak sa app sandbox. Parehong nangangailangan ng pahintulot sa EEA, ngunit ang mga legal na batayan at prompt ay natatangi. Sa Android ang parehong lohika ay naaangkop na may Amplitude.getInstance().initializeApolloClient() o ang katumbas depende sa bersyon ng SDK.

Server-side mode

Sinusuportahan ng Amplitude ang server-side na pagpasok sa pamamagitan ng HTTP V2 API. Ang mga server-side event ay hindi exempt mula sa pahintulot — ang legal na batayan ay sumusunod sa data, hindi sa transport — ngunit ang server-side na pagpasok ay nagbibigay sa publisher ng ganap na kontrol kung aling mga field ang ipadala, na nagpapadali sa paggalang sa bahagyang pahintulot. Ang isang karaniwang pattern ay ang kumuha ng isang minimal na essential-only event set server-side sa ilalim ng legitimate interest, at pagpapayaman lamang ng mga event na iyon ng behavioral detail pagkatapos na maibigay ng user ang analytics consent sa client.

Pag-validate ng integrasyon

Ang hakbang sa validation ay ang isa na kadalasang nilaktawan ng mga publisher at kadalasang sinisiyasat ng mga regulator. Ang isang wastong na-integrate na deployment ng Amplitude ay dapat pumasa sa apat na tseke. Una, ang isang browser na may ipinakitang consent banner ngunit walang pagpipiliang ginawa ay dapat gumawa ng zero na request sa api.amplitude.com o api.eu.amplitude.com at zero na AMP_ cookie sa document.cookie. Pangalawa, ang pagtanggi sa kategorya ng analytics ay dapat mapanatili ang estado na iyon — walang event, walang cookie, walang local storage entry na may prefix na AMP_. Pangatlo, ang pagtanggap ng analytics ay dapat gumawa ng isang identify na sinusundan ng trapiko ng event, at ang AMP_ cookie ay dapat lumabas na may SameSite attribute na naaayon sa patakaran ng CMP ng publisher. Pang-apat, ang pag-withdraw ng pahintulot pagkatapos nito ay dapat agad na itigil ang karagdagang mga event at linisin ang nakaimbak na mga identifier — ang naantalang paglilinis ay isang natuklasan.

Ang audit trail ay mahalaga nang hiwalay. Sa ilalim ng mga alituntunin ng cookie banner ng EDPB noong 2023 at ang mga na-renew na priyoridad ng task force para sa 2026, inaasahan ng mga regulator na ang publisher ay makapagpapatunay, para sa anumang ibinigay na event sa proyekto ng Amplitude, na ang user na bumuo nito ay nagbigay ng wastong pahintulot sa sandali ng pagkuha. Nangangailangan ito ng log ng pahintulot ng CMP na maaaring i-query ayon sa device identifier o session identifier, at ang event payload ng Amplitude ay nagdadala ng consent-version field na bumabalik sa log na iyon. Ang pag-iimbak ng consent string bilang isang custom user property sa bawat event ay ang pinakasimpleng paraan upang gawing maaaudit ang link na iyon.

Pagpili ng tamang rehiyon at data residency

Nagpapatakbo ang Amplitude ng dalawang production region: ang US (api.amplitude.com) at ang EU (api.eu.amplitude.com). Para sa trapiko ng EEA at UK ang EU region ay ang tamang default — pinapanatili nito ang data sa loob ng EEA at binabawasan ang transfer-risk surface na ginawang sentral ng desisyon ng Schrems II at ng EU-US Data Privacy Framework sa anumang pagsusuri ng analytics. Ang pagpapalit ng mga rehiyon ay hindi retroactive: ang umiiral na data ay nananatili kung saan ito unang na-ingest. Para sa mga publisher na nagpaplano ng CMP rollout ito ay sulit na kumpirmahin ang rehiyon bago i-scale, at sulit na idokumento ang pagpipilian sa abiso sa privacy upang ang chain ng legal na batayan ay malinis mula sa koleksyon hanggang sa storage. Ang tamang napiling rehiyon, ipinares sa tamang gated na SDK at isang maaari-i-query na consent log, ay ang ginagawang deployment ng Amplitude mula sa isang regulatory risk patungo sa isang mapagtatanggol na bahagi ng analytics stack.