Permukaan Pelacakan SFMC

Untuk keperluan persetujuan, lebih baik memperlakukan SFMC bukan sebagai produk tunggal tetapi sebagai empat permukaan pelacakan yang saling tumpang tindih, masing-masing dengan pola integrasi tersendiri.

Web Analytics Connector dan Kode Pelacakan Collect

Kode pelacakan Collect (sering disebut collect.js atau direferensikan melalui cdn.evgnet.com) adalah pelacak perilaku SFMC. Ini mengatur cookie _etmc dan cookie terkait, mengidentifikasi pengunjung lintas sesi, dan meneruskan peristiwa tampilan halaman, klik, dan konversi ke SFMC untuk digunakan dalam pemicu Journey Builder dan retargeting email. Dari perspektif regulasi, ini jelas merupakan pelacak pemasaran — meskipun peristiwanya tampak seperti analitik, data tersebut mendukung otomasi pemasaran langsung.

Skrip Marketing Cloud Personalization

Skrip Personalization (Interaction Studio warisan) lebih berat dari Collect. Ia memuat SDK yang memantau seluruh DOM, menangkap data aliran klik dan interaksi formulir, serta meneruskannya ke mesin keputusan personalisasi yang dapat menulis ulang konten halaman secara real time. Cookie yang ditetapkan mencakup pengidentifikasi _ev_* dan token sesi. Ini adalah pemrosesan bertujuan pemasaran yang tidak ambigu dan memerlukan persetujuan opt-in di yurisdiksi EU atau UK mana pun.

Formulir CloudPages dan tautan terlacak

Halaman arahan yang dihosting CloudPages dan tautan email terlacak yang dirutekan melalui SFMC membawa parameter pengidentifikasi tersendiri (subscriberkey, jb, parameter mid dalam URL). Ketika pengunjung tiba melalui tautan terlacak, SFMC dapat mengkorelasikan sesi dengan catatan pelanggan mereka bahkan sebelum pelacakan dalam halaman diaktifkan. Ini adalah posisi hukum yang berbeda secara bermakna dari pelacakan anonim — identitas pelanggan diketahui pada kontak pertama — dan persetujuan untuk komunikasi pemasaran harus sudah ada.

Konektor Data Cloud

Integrasi Data Cloud SFMC (lapisan platform data pelanggan) menarik pengidentifikasi dari pelacakan web, SDK seluler, catatan CRM, dan data offline ke dalam profil terpadu. Status persetujuan perlu disebarluaskan ke Data Cloud, bukan hanya ke piksel pelacakan tingkat permukaan, sehingga aktivasi hilir ke jaringan iklan menghormati preferensi yang dicatat pengunjung.

Kontrol Privasi SFMC Native

SFMC mengekspos beberapa kontrol native tetapi, seperti kebanyakan platform pemasaran enterprise, mereka mengasumsikan bahwa keputusan persetujuan telah dikumpulkan di hulu dan sedang diteruskan. Kontrol native tidak mengumpulkan persetujuan sendiri.

Opt-out pelacakan untuk Web Analytics Connector

Skrip Collect membaca tanda do_not_track dan fungsi opt-out yang dapat dikonfigurasi. Mengatur ini mencegah Collect mengirim data tetapi tidak mencegah skrip itu sendiri dimuat. Untuk yurisdiksi persetujuan-sebelumnya, Anda perlu membatasi pemuatan skrip, bukan hanya mengaktifkan/menonaktifkan tanda.

Preferensi persetujuan dalam catatan pelanggan

Profil pelanggan di SFMC memiliki kolom untuk persetujuan komunikasi, persetujuan data profil, dan dasar hukum. Ini adalah primitif yang tepat untuk melacak dasar hukum di mana kontak yang dikenal dipasarkan, dan CMP harus menulis kembali ke kolom-kolom ini ketika pengunjung menerima atau mencabut persetujuan.

Persetujuan Marketing Cloud Personalization

SDK Personalization menerima tanda persetujuan selama inisialisasi. Tetapkan ke false hingga pengguna menerima kategori pemasaran di banner CMP, lalu inisialisasi ulang SDK ketika persetujuan diberikan.

Integrasi CMP Langkah demi Langkah

Arsitektur yang andal adalah membatasi semua empat permukaan pelacakan di belakang CMP dan menggunakan tanda native SFMC untuk menyempurnakan perilaku hilir setelah persetujuan diberikan.

1. Hentikan skrip Collect dari pemuatan secara default

Hapus skrip Collect dari kepala dokumen dan ganti dengan placeholder yang dapat diaktifkan CMP. Ketika pengunjung menerima kategori pemasaran, CMP menulis ulang placeholder untuk memuat collect.js. Semua peristiwa yang diantrekan akan diproses saat pemuatan.

2. Tunda inisialisasi Marketing Cloud Personalization

Skrip Personalization tidak boleh diinisialisasi sebelum persetujuan. Sebagian besar CMP menangani ini dengan pola pemuatan-tertunda: elemen skrip hadir di DOM tetapi atribut type-nya adalah text/plain, dan CMP menulis ulangnya ke text/javascript saat persetujuan diterima.

3. Batasi parameter pelacakan CloudPages

Jika pengunjung tiba melalui tautan terlacak dan belum memberikan persetujuan, parameter subscriberkey yang masuk harus ditangkap tetapi tidak digunakan untuk mendorong personalisasi langsung. Pola yang tepat adalah menyimpannya dalam status sesi dan hanya mengaktifkannya (menghubungkan dengan data profil, memicu peristiwa Journey Builder) setelah persetujuan dicatat.

4. Sebarluaskan status persetujuan ke Data Cloud

Integrasi Data Cloud perlu mengetahui status persetujuan setiap pengunjung sehingga aktivasi hilir menghormatinya. SFMC mendukung ekstensi persetujuan yang memungkinkan CMP menulis catatan persetujuan ke Data Cloud melalui API. Konfigurasikan ini sehingga keputusan persetujuan CMP menjadi sumber kebenaran di seluruh lapisan SFMC, bukan hanya untuk skrip di halaman.

5. Petakan ke kolom persetujuan pelanggan SFMC

Ketika pelanggan yang dikenal memperbarui persetujuan mereka di pusat preferensi CloudPages, CMP dan catatan pelanggan SFMC perlu tetap sinkron. Konfigurasikan write-back dari CMP ke kolom persetujuan pelanggan SFMC, dan konfigurasikan read-back sehingga banner di halaman menghormati apa yang ditetapkan pelanggan dalam preferensi email mereka.

Kesalahan Umum

Tiga kesalahan integrasi menyumbang sebagian besar temuan audit enterprise pada SFMC.

Memperlakukan Collect sebagai analitik

Karena skrip Collect melaporkan tampilan halaman dan peristiwa klik yang tampak seperti analitik, tim terkadang membatasinya di bawah kategori persetujuan analitik. SFMC menggunakan data tersebut untuk mendorong otomasi pemasaran Journey Builder, yang merupakan pemrosesan bertujuan pemasaran yang tidak ambigu. Batasi Collect di bawah pemasaran.

Membiarkan Personalization berjalan sebelum persetujuan

Personalization adalah permukaan pelacakan SFMC yang paling berat dan paling terlihat oleh regulator karena secara aktif memodifikasi halaman. Membiarkannya diinisialisasi sebelum persetujuan adalah, dalam istilah audit, pola yang paling mengekspos dalam tumpukan SFMC.

Tidak menyinkronkan persetujuan di seluruh tumpukan

Jika banner di halaman mencatat keputusan persetujuan tetapi profil Data Cloud mempertahankan status yang lebih lama, aktivasi hilir ke jaringan iklan akan terus diaktifkan berdasarkan persetujuan yang sudah usang. CMP harus memiliki sumber kebenaran dan menyebarluaskannya ke mana pun tumpukan SFMC dapat menjangkau.

Daftar Periksa Audit

Lima pertanyaan konkret untuk dijawab untuk setiap penerapan SFMC yang menyentuh lalu lintas EU, UK, atau California.

• Apakah Collect menunggu persetujuan? Konfirmasi tidak ada permintaan collect.js atau evgnet.com yang diaktifkan sebelum penerimaan banner.
• Apakah Personalization ditunda? Konfirmasi SDK Personalization tidak diinisialisasi hingga kategori pemasaran diberikan.
• Apakah parameter tautan terlacak masuk ditahan hingga persetujuan? Konfirmasi personalisasi berbasis subscriberkey menunggu sinyal persetujuan eksplisit.
• Apakah Data Cloud melihat status persetujuan? Konfirmasi ekstensi persetujuan dikonfigurasi dan CMP menulis keputusan ke Data Cloud secara real time.
• Apakah kolom persetujuan pelanggan disinkronkan? Konfirmasi perubahan pusat preferensi disebarluaskan ke banner di halaman dan sebaliknya.

Tempat SFMC dalam Tumpukan Persetujuan-Pertama

SFMC adalah salah satu platform pemasaran yang paling kuat — dan salah satu yang paling mengekspos — yang dapat diterapkan oleh enterprise. Pola instalasi default tidak memenuhi ekspektasi Eropa atau California saat ini, dan kontrol native platform adalah primitif yang berguna tetapi bukan pengganti lapisan manajemen persetujuan di hulu. Arsitektur yang tepat memperlakukan CMP sebagai sumber kebenaran tunggal, membatasi setiap modul pelacakan di belakangnya, dan menggunakan ekstensi persetujuan SFMC untuk membuat Data Cloud dan catatan pelanggan menyebarluaskan kebenaran tersebut di seluruh sisa tumpukan. Jika dilakukan dengan benar, SFMC terus melakukan apa yang dibeli oleh pemasar — pemicu Journey Builder, pengambilan keputusan Personalization, aktivasi Data Cloud — sementara posisi kepatuhan yang mendasarinya sesuai dengan apa yang sekarang diharapkan oleh regulator dari setiap pemasar enterprise.