Cara Tim Pemasaran Menerapkan Aplikasi Buatan AI Tanpa Membocorkan Data Pelanggan Email

Peneliti keamanan Joel Margolis mengatakan kepada Wired, “Seseorang dari tim pemasaran ingin membuat situs web. Mereka bukan insinyur dan mungkin nyaris tidak memiliki latar belakang atau pengetahuan keamanan.” Laporan Wired yang sama menyebut perusahaan keamanan RedAccess menemukan lebih dari 5.000 aplikasi hasil vibe coding yang hampir tanpa keamanan atau autentikasi, dan sekitar 40 persennya membocorkan data sensitif. Wired tidak dapat memastikan apakah data pribadi atau perusahaan yang diperiksanya asli.

Aplikasi buatan AI untuk tim pemasaran menghadapi bentuk khusus masalah tersebut. Alat yang layak dibuat, seperti pembuat segmen, dasbor kampanye, penganalisis A/B, dan sinkronisasi audiens, justru terhubung ke daftar pelanggan email, sering kali juga ke akun iklan.

TL;DR

• Berikan setiap kunci API platform email dan token akun iklan akses tersempit yang dipakai alat, lalu simpan dalam kode sisi server. Marketing API Mailchimp tidak memiliki jenis kunci yang lebih terbatas, sehingga pekerjaan Mailchimp hanya baca mendapat ekspor terbatas berisi data yang diperlukan saja, bukan kunci.
• Platform email tetap menjadi sumber acuan status langganan. Alat tidak pernah mendaftarkan kembali orang yang menolak, meneruskan permintaan berhenti berlangganan ke platform, dan menyertakan tautan berhenti yang berfungsi dalam setiap email pemasaran yang dikirimnya sendiri.
• Unggahan audiens khusus yang di-hash tetap merupakan data pribadi: tentukan data yang boleh masuk ke platform iklan dan layanan AI sebelum dikirim, dan pastikan setiap penghentian langganan sampai ke audiens iklan.
• GDPR mengatur penyimpanan dan penggunaan daftar, termasuk pemberitahuan pelanggaran dan hak tanpa syarat untuk menolak pemasaran; ePrivacy/PECR, CAN-SPAM, atau CASL mengatur pengiriman email, termasuk oleh alat internal.

Kesalahan Penerapan yang Membocorkan Data Pelanggan atau Melanggar Persetujuan

Alat pemasaran buatan AI biasanya menimbulkan masalah daftar dengan dua cara: daftar keluar melalui kunci, tautan publik, atau unggahan, atau dipakai terhadap orang yang sudah menolak. Token iklan dengan akses kelola menambah risiko terpisah: pengeluaran pada akun iklan perusahaan.

Alat pemrograman AI yang membuat aplikasi dapat melakukan sebagian besar perbaikan ini jika diminta. Jadikan setiap prompt berikut sebagai titik awal untuk disesuaikan, dan simpan yang digunakan dalam berkas aturan yang dibaca alat AI setiap sesi. Laporan AI bahwa perubahan sudah dibuat bukan bukti; langkah Verifikasi: di bawah setiap prompt-lah buktinya. Minta AI menandai ketidakpastian alih-alih menebak, dan jangan tempelkan kunci aktif atau ekspor pelanggan ke percakapan.

Ganti Kunci Platform Email Berakses Penuh dengan yang Paling Terbatas

Pembuat segmen yang hanya menampilkan jumlah tidak memerlukan kunci yang bisa mengekspor daftar atau mengirim kampanye, tetapi kunci terluas setiap platform di bawah bisa melakukan keduanya. Lokasi penyimpanan juga penting: kode browser membutuhkan nilai kunci itu sendiri untuk memanggil API, sehingga siapa pun yang memuat halaman bisa membacanya. Mailchimp sama sekali tidak mendukung penggunaan API di sisi klien.

Setiap baris mengikuti dokumentasi platform sendiri: halaman bantuan kunci API Mailchimp, izin kunci API SendGrid, panduan autentikasi Klaviyo, dan dokumentasi kunci API Mailgun. Izin Listmonk dijelaskan pada bagian Listmonk di bawah.

Alat mendapat kunci tersempit yang diizinkan pekerjaannya, atau tanpa kunci. Di Mailchimp, pekerjaan hanya baca seperti laporan dan jumlah segmen lebih tepat memakai pelaporan bawaan atau ekspor terbatas oleh pemilik akun yang hanya memuat kolom yang diperlukan. Imbalannya adalah waktu seseorang dan data yang hanya mutakhir sampai saat ekspor; pekerjaan perubahan dan pengiriman diserahkan ke TI atau tetap di Mailchimp. Pada platform lain seperti ActiveCampaign atau Brevo, cari opsi kunci terbatas terlebih dahulu.

Kunci kemudian hanya berada dalam kode sisi server, yaitu backend alat yang tidak pernah diunduh browser, sebagai variabel lingkungan: nilai yang diberikan server saat aplikasi mulai, tidak masuk kode maupun repositori.

Temukan setiap kunci API, token akses, kata sandi, atau rahasia dalam proyek ini untuk platform email kita, baik Mailchimp, Klaviyo, SendGrid, Mailgun, Listmonk, maupun lainnya, dan platform iklan seperti Meta, Google Ads, LinkedIn, atau lainnya. Gunakan pemindai rahasia lokal atau metode yang disetujui TI untuk memeriksa kode, berkas lingkungan, dan riwayat repositori. Jangan kirim nilai rahasia mentah, isi berkas lingkungan, atau riwayat berisi kredensial ke layanan AI eksternal. Berikan AI hanya temuan yang disamarkan, termasuk lokasi berkas dan jenis kredensial. Untuk setiap temuan, jelaskan:

- berkas dan baris

- apakah nilai ditulis langsung dalam kode atau dibaca dari variabel lingkungan

- apakah kode yang memakainya berjalan di server atau browser

Tampilkan hanya empat karakter pertama setiap nilai. Jangan pernah mencetak kunci atau token lengkap.

Tandai kredensial yang bisa mengirim email, mengubah pelanggan, atau mengelola akun iklan sebagai prioritas tertinggi.

Lalu pindahkan semua panggilan yang membutuhkan kunci API privat atau token akses ke kode sisi server yang membaca kredensial dari variabel lingkungan khusus server. Sisakan hanya panggilan API publik sisi klien yang terdokumentasi di browser, hapus kunci privat yang terungkap dari kode, dan kecualikan berkas dengan rahasia asli dari repositori. Laporkan perubahan secara tepat dan jelaskan ketidakpastian alih-alih menebak.

Catatan: Menghapus kunci yang sudah ditempel dari percakapan atau kode tidak membatalkan pembagiannya. Cabut kunci tersebut, yaitu nonaktifkan melalui pengaturan platform agar berhenti berfungsi, lalu buat yang baru.

Verifikasi: buka alat, tekan F12, pilih tab Network, lalu gunakan seperti tim akan menggunakannya sambil membaca domain setiap permintaan. Permintaan browser yang langsung memanggil API privat platform email adalah tanda peringatan, tetapi tujuan saja tidak membuktikan rahasia terungkap. Periksa header permintaan dan kode untuk kredensial privat, tanpa menyalin nilainya ke percakapan AI. Permintaan SDK publik sisi klien berbeda: permintaan ini dapat secara sah menggunakan pengenal publik, bukan kunci API rahasia. Di Klaviyo, permintaan ke a.klaviyo.com/client/ memakai kunci publik dan tepat berada di browser, sedangkan permintaan browser ke a.klaviyo.com/api/ perlu diselidiki karena endpoint itu biasanya perlu autentikasi kunci privat. Pastikan apakah kredensial privat benar-benar dikirim.

Sisanya ditangani manusia: buat kunci terbatas dari akun yang tidak dimiliki satu orang karena Mailchimp menghapus kunci API pengguna ketika aksesnya dicabut; beri nama sesuai alat karena Mailchimp menyarankan satu kunci per integrasi; minta TI menyimpannya di tempat kunci alat disimpan. Untuk rotasi terencana, alihkan alat ke kunci baru sebelum mencabut yang lama karena kunci Mailchimp yang dicabut tidak bisa diaktifkan lagi. Jika kunci sudah dibobol, cabut segera dan ganti. Rencanakan pula kedaluwarsa: kunci API Mailchimp yang dibuat pada atau setelah 22 Juni 2026 kedaluwarsa setahun setelah pembuatan.

Berikan Token Akun Iklan Hanya Izin yang Digunakan Alat

Saya menganggap token akun iklan sebagai kredensial berdampak tertinggi yang bisa dimiliki alat pemasaran karena terhubung dengan pengeluaran. Token Meta berakses kelola dapat membuat, mengubah, atau menjeda kampanye yang ditagihkan ke akun iklan perusahaan, serta membaca pengeluaran dan kinerja.

Token tersebut tidak mengembalikan daftar pelanggan email yang diunggah ke audiens khusus. Panduan Custom Audiences Meta menggunakan nilai hash SHA-256 untuk menambah dan menghapus orang, yaitu pengacakan satu arah setiap alamat yang dibandingkan platform dengan catatannya sendiri. Tidak ada endpoint terdokumentasi yang mengembalikan daftar terbaca dari audiens yang sudah ada.

Referensi izin Meta menjelaskan setiap izin dan meminta pengembang memilih hanya yang dibutuhkan aplikasi. Setiap alat mendapat token sendiri dari pengguna sistem, istilah Meta untuk akun dalam Business Manager yang digunakan perangkat lunak, dan ditetapkan hanya ke akun iklan yang ditangani alat itu. Jangan masukkan token login pribadi pembuat ke alat; simpan token pengguna sistem di server seperti kunci email. Inventaris yang sama berlaku untuk akses Google Ads atau LinkedIn.

Daftarkan semua panggilan alat ini ke Marketing API Meta, Google Ads, atau platform iklan lain, termasuk lewat pustaka pembantu atau SDK. Untuk setiap panggilan, berikan:

- berkas dan baris

- endpoint atau metode SDK

- label REPORT untuk membaca metrik atau pengeluaran, MANAGE untuk membuat atau mengubah kampanye, iklan, anggaran, atau audiens, atau LEADS untuk membaca kiriman formulir prospek

- izin platform yang diperlukan label itu

Tandai token yang dipakai lebih dari satu alat dan kode yang mengirim token ke browser. Jangan cetak nilai token. Jika tidak bisa menentukan label yang diperlukan suatu panggilan, nyatakan demikian.

Verifikasi: periksa token dasbor dengan alat debugging token Meta yang melaporkan izin token, lalu bandingkan dengan label prompt. Token dasbor pelaporan seharusnya memiliki ads_read dan tidak ada izin pengelolaan akun; label MANAGE atau LEADS pada alat pelaporan adalah temuan. Kemudian pastikan dalam Business settings bahwa alat memakai token pengguna sistem, bukan token pribadi pembuat.

Tutup Alamat Terbuka dan Tampilkan Baris Pelanggan Hanya kepada Admin Daftar

Aplikasi pada hosting milik alat AI dapat dibuka siapa pun yang menemukan alamatnya. Menurut Wired, sebagian aplikasi yang diperiksa RedAccess hanya memiliki hambatan sepele, seperti meminta pengunjung masuk dengan alamat email apa pun. Hosting semacam itu cocok untuk demo dengan alamat rekaan, sesuai tujuan hosting gratis dan tunnel.

Separuh lainnya adalah apa yang dilihat tiap orang setelah masuk. Tugas dasbor kampanye adalah angka tingkat kampanye: tingkat buka, klik, hasil A/B, dan ukuran segmen. Baris pelanggan di baliknya, yaitu setiap alamat beserta rincian persetujuan dan riwayat interaksi, merupakan data pribadi.

Angka agregat yang dianonimkan dengan benar umumnya bukan data pribadi, tetapi segmen kecil atau rincian mendalam masih bisa mengidentifikasi orang. Angka anonim pun bisa mengungkap informasi persaingan perusahaan, dan penganalisis A/B yang menyimpan buka serta klik per orang juga menyimpan data pribadi. Tim melihat agregat; hanya pengelola daftar yang melihat baris, dan server menegakkannya pada setiap permintaan.

Daftarkan setiap kolom di basis data, layar, ekspor, dan respons API aplikasi yang memuat data pribadi pelanggan: alamat email, nama, telepon, alamat pos, alamat IP, lokasi, status langganan, sumber dan tanggal-waktu persetujuan, tanggal langganan, status berhenti, serta buka dan klik per orang. Untuk setiap kolom, jelaskan layar dan ekspor yang menampilkannya. Tandai ketidakpastian alih-alih menebak.

Lalu tambahkan dua peran, diambil dari akun yang masuk dan diperiksa di server untuk setiap halaman, ekspor, dan rute API:

- admin daftar: dapat melihat baris pelanggan dan menjalankan ekspor

- pemasar: hanya melihat angka kampanye, jumlah segmen, dan hasil A/B, tanpa baris per orang dan tanpa ekspor

Tolak semua yang lain dengan respons “akses ditolak” (403). Laporkan pemeriksaan yang melindungi tiap halaman dan rute.

Apakah data tersimpan dienkripsi pada disk adalah pertanyaan untuk TI; alat AI tidak dapat memastikannya hanya dengan membaca kode.

Verifikasi: buat akun uji dengan peran pemasar. Setelah masuk, buka dasbor kampanye yang seharusnya termuat, lalu halaman daftar pelanggan dan ekspor yang keduanya seharusnya berhenti pada “akses ditolak”. Lalu buka alamat alat dari ponsel dengan data seluler saat keluar dari akun: tidak ada yang termuat atau berhenti pada halaman login perusahaan.

Serahkan Penghentian Langganan dan Catatan Persetujuan kepada Platform Email

Alat yang menyimpan salinan daftar sendiri lalu mengirimkannya kembali lewat sinkronisasi dua arah atau impor ulang ekspor bulan lalu dapat menandai orang yang berhenti sebagai berlangganan lagi dan menghilangkan catatan tempat, waktu, serta cara pendaftarannya. Biasanya alat tidak menunjukkan tanda sampai orang itu menerima kampanye berikutnya, ketika aturan pengiriman di bawah berlaku. Empat aturan mencegahnya:

1. Platform email adalah sumber acuan status langganan. Alat membaca status itu dan tidak pernah mendaftarkan ulang atau menimpa pelanggan yang sudah ada. Alat boleh meneruskan permintaan berhenti yang eksplisit melalui proses berhenti yang ditetapkan platform.
2. Tidak ada impor massal atau sinkronisasi yang mengganti catatan pelanggan lama atau menimpa informasi langganan dan persetujuannya. Alat yang ditinjau boleh memperbarui kolom yang disetujui secara eksplisit, misalnya tag, tanpa mengubah status. Pendaftaran baru masuk lewat formulir atau jalur impor platform sendiri agar penanganan opt-in berlaku; formulir milik alat setelah ditinjau boleh menambah pelanggan baru beserta sumber, tanggal-waktu, dan formulir, tetapi tidak mendaftarkan ulang kontak lama atau menimpa informasi langganan maupun persetujuannya.
3. Semua pengiriman dan ekspor alat membaca status dari platform saat itu, bukan salinan sendiri. Ekspor mengecualikan kontak yang berhenti dan diblokir, atau menandainya sebagai daftar jangan-kirim yang tidak pernah digunakan untuk pengiriman.
4. Kolom persetujuan berupa sumber, tanggal-waktu, formulir atau metode tetap utuh bersama setiap catatan yang disalin alat; jika tidak, alat tidak menyalinnya dan tidak mengaku memilikinya.

Daftarkan setiap tempat alat ini menulis ke platform email atau salinan daftar pelanggan: panggilan API yang membuat atau memperbarui pelanggan, impor, sinkronisasi, dan ekspor berkas. Untuk masing-masing, jelaskan apakah bisa:

- mengubah status langganan pelanggan lama

- menimpa catatan pelanggan lama

- menyertakan kontak yang berhenti atau diblokir

Untuk setiap jalur yang mengirim email atau mengekspor daftar untuk pengiriman, jelaskan apakah status dibaca dari platform email saat itu atau dari salinan alat sendiri.

Lalu ubah alat agar tidak pernah mendaftarkan ulang kontak lama atau menimpa status langganannya, kecuali meneruskan permintaan berhenti yang eksplisit lewat proses resmi platform. Jangan mengganti seluruh catatan pelanggan lama, baca status platform tepat sebelum pengiriman atau ekspor, dan pertahankan sumber, tanggal-waktu, serta formulir persetujuan pada setiap catatan salinan. Laporkan perubahan dan ketidakpastian.

Catatan: Ekspor lama yang diimpor ulang menimpa daftar membawa status lamanya, sehingga siapa pun yang berhenti setelah ekspor itu bisa kembali berstatus berlangganan, tergantung penanganan impor platform dan alat.

Verifikasi: tambahkan pelanggan uji di platform email lalu hentikan langganannya di sana. Jalankan sinkronisasi, pembuat segmen, dan ekspor alat. Di platform pelanggan itu harus tetap berhenti; di ekspor harus tidak ada atau ditandai jangan-kirim; di semua daftar kirim yang dibuat alat ia tidak muncul.

Kirim lewat Platform Email, atau Bangun Jalur Berhenti Terlebih Dahulu

Alat pengirim re-engagement yang mengirim langsung ke daftar lewat akun SMTP atau API email transaksional tidak mendapat tambahan platform untuk email pemasaran, yaitu tautan berhenti, alamat pos, dan pemeriksaan blokir, kecuali kodenya menambahkan semuanya. Solusinya adalah membiarkan platform atau Listmonk mengirim, sementara alat membuat segmen atau memicu kampanye platform. Alat yang harus mengirim sendiri adalah alat pengiriman yang pada bagian berikutnya diarahkan ke TI.

Alat itu membutuhkan tautan berhenti pada setiap pesan pemasaran yang tetap berfungsi setelah pengiriman, serta identitas dan alamat pos pengirim di footer, sesuai tenggat pada tabel hukum di bawah. Alat juga membutuhkan daftar blokir sendiri, diperiksa sebelum setiap pengiriman dan disimpan sebagai catatan blokir yang tahan lama, dengan cadangan serta pemulihan yang mencegah basis data pelanggan lama menimpa penolakan baru. CAN-SPAM memperlakukan pesan transaksional secara berbeda.

Bagi pengirim bervolume tinggi, tautan footer mungkin tidak cukup. Gmail mewajibkan pengirim 5.000 pesan atau lebih per hari ke akun Gmail pribadi mendukung berhenti sekali klik RFC 8058 untuk pesan pemasaran dan langganan. Artinya menambahkan header List-Unsubscribe dan List-Unsubscribe-Post bersama tautan berhenti yang terlihat. Endpoint sekali klik harus memproses POST; membuka URL dengan GET saja tidak boleh menghentikan langganan. Minta TI memverifikasi sebelum mengirim pada skala tersebut.

Tambahkan tautan berhenti pada setiap pesan pemasaran yang dikirim alat ini, beserta endpoint berhenti di belakangnya.
Jika alat tunduk pada persyaratan pengirim massal Gmail, implementasikan pula header berhenti sekali klik RFC 8058 yang dicakup tanda tangan DKIM valid dan endpoint berbasis POST. Jangan memicu berhenti hanya karena URL dibuka. Tandai ketidakpastian untuk tinjauan TI.
Ketika endpoint berhenti menerima permintaan valid melalui klik tautan, pengiriman formulir, atau panggilan API:

- segera tambahkan alamat ke daftar blokir pengiriman yang disimpan terpisah dari tabel pelanggan

- catat tanggal-waktu serta saluran permintaan

- jika platform email kita memegang daftar, beri tahu platform untuk menghentikan alamat itu juga

Periksa daftar blokir sebelum setiap pengiriman dan lewati yang cocok. Jangan otomatis menghapus alamat dari daftar blokir saat impor, sinkronisasi, atau pemulihan basis data. Simpan hanya informasi blokir minimum yang diperlukan untuk menghormati penolakan, mengikuti kebijakan retensi perusahaan yang disetujui, dan jangan biarkan impor atau sinkronisasi menambah kembali alamat terblokir. Pastikan cadangan mencakup daftar blokir dan pemulihan tabel pelanggan tidak mengubahnya. Tambahkan nama pengirim serta alamat pos ke footer setiap pesan pemasaran dengan placeholder yang akan saya isi. Laporkan perubahan dan pengiriman yang dicakup.

Verifikasi: tambahkan alamat uji yang Anda kuasai ke daftar uji, kirim kampanye uji lewat alat, lalu klik tautan berhenti dalam pesan yang diterimanya. Alamat itu sekarang harus ada di daftar blokir dan berstatus berhenti di platform jika platform memegang daftar. Kirim lagi ke daftar uji yang sama: alamat itu tidak menerima apa pun.

Penanggung jawab kepatuhan email perusahaan menyediakan nama pengirim dan alamat pos untuk placeholder tersebut.

Tentukan Data yang Keluar ke Platform Iklan dan AI Sebelum Dikirim

Dua jalur kode mengirim data pelanggan keluar secara default: sinkronisasi yang mengunggah segmen ke audiens khusus Meta atau Google, dan panggilan yang meneruskan kolom pelanggan ke API AI untuk menulis subjek atau menilai prospek, atau ke skrip analitik serta webhook.

Meta dan Google bisa mencocokkan audiens pelanggan dengan pengenal kontak yang di-hash SHA-256. Data Manager API Google mewajibkan alamat email dan nomor telepon dinormalisasi serta di-hash sebelum pengiriman, sedangkan sebagian unggahan lewat antarmuka Google Ads dapat melakukan hashing selama proses unggah. Hashing adalah cara platform mencocokkan alamat dengan profil; bukan membuat orang anonim (lihat FAQ).

Untuk integrasi Google Customer Match baru, periksa API unggahan yang didukung sebelum membangun sinkronisasi. Sejak 1 April 2026, Google membatasi metode unggahan Customer Match lama untuk pengguna baru dan mengarahkan integrasi itu ke Data Manager API.

Ketentuan audiens daftar pelanggan Meta mengharuskan pengiklan menjamin bahwa ia memiliki hak, izin, dan dasar hukum yang diperlukan untuk berbagi data. Kebijakan Customer Match Google mewajibkan pengungkapan pembagian itu dalam kebijakan privasi dan persetujuan jika diwajibkan hukum.

Demi kesederhanaan, alat ini memperlakukan setiap penghentian langganan juga sebagai permintaan berhenti mencocokkan iklan. Ini kebijakan perusahaan yang konservatif, bukan klaim bahwa setiap penghentian email pada satu saluran secara hukum mengharuskan penghapusan dari semua audiens iklan.

Karena itu jalur unggah hanya boleh menerima segmen yang disetujui perusahaan untuk pencocokan iklan. Perusahaan harus menetapkan dasar hukum yang tepat dengan panduan pemimpin privasi atau petugas perlindungan data (DPO) jika telah ditunjuk. Kontak yang berhenti dan diblokir tidak masuk unggahan mana pun, dan penghentian memicu penghapusan berdasarkan hash dari setiap audiens (alasan dijelaskan pada bagian GDPR).

Setiap layanan AI atau analitik yang menerima data pelanggan harus disetujui perusahaan. Sebelum berbagi data pribadi, pastikan penyedia bertindak sebagai prosesor atau pengendali independen dan terapkan perlindungan kontraktual yang tepat, termasuk perjanjian pemrosesan data jika diperlukan.

Audit setiap panggilan keluar alat ini: platform email, iklan termasuk unggahan audiens, API AI seperti OpenAI atau Anthropic maupun lainnya, alat analitik, dan webhook. Untuk tiap panggilan, daftarkan tepat kolom pelanggan dalam isi permintaan atau URL. Jelaskan panggilan yang bisa bekerja dengan lebih sedikit kolom atau tanpa data pelanggan. Akhiri dengan nama semua layanan luar agar bisa dicocokkan dengan vendor yang disetujui.

Verifikasi: setiap kolom pelanggan untuk layanan AI atau analitik dalam laporan harus diperlukan tugas, dan semua layanan harus ada di daftar perusahaan yang disetujui; yang tidak ada diteruskan ke penandatangan kontrak vendor.

Untuk setiap jalur alat ini yang mengunggah kontak ke Meta, Google Ads, atau platform iklan lain:

- hash alamat email dan nomor telepon dengan SHA-256 di server sebelum unggah, mengikuti aturan normalisasi tiap platform

- unggah hanya kontak dalam [segmen yang disetujui perusahaan untuk pencocokan iklan]

- kecualikan kontak yang berhenti dan diblokir pada saat unggah

- saat kontak berhenti, kirim penghapusan nilai hash-nya ke setiap audiens tujuan unggah sebelumnya

- catat setiap unggahan dan penghapusan beserta tanggal-waktu, audiens, jumlah kontak, serta pengguna atau pekerjaan pemicunya

Laporkan perubahan dan tandai ketidakpastian.

Verifikasi: hentikan langganan kontak uji dalam segmen yang diunggah. Setelah sinkronisasi berikutnya, periksa permintaan penghapusan dikirim ke semua audiens terkait. Pastikan setiap platform iklan berhasil memproses penghapusan, bukan sekadar alat mencatat atau mengirimnya. Tandai penghapusan gagal atau sebagian selesai untuk dicoba ulang dan ditinjau TI.

Pekerjaan terhadap Daftar Menentukan Tempat Alat Berjalan

Alat yang hanya menampilkan angka kampanye berjalan di server kendali tim, hanya dapat dijangkau dari jaringan privat. Alat yang menampilkan baris pelanggan menambahkan login perusahaan karena peran bergantung padanya. Alat pengirim pemasaran atau sinkronisasi audiens tetap dalam fitur platform sendiri, atau ditangani TI sebelum siapa pun menggunakannya.

Persetujuan mengikuti tiap baris: dua baris hanya baca memerlukan admin platform email menerbitkan kunci, baris pengubah daftar perlu pembaca kedua, dan baris pengiriman perlu TI serta tinjauan privasi untuk unggahan audiens.

Jaringan privat berarti alat sama sekali tidak merespons dari luar. Halaman login buatan AI dapat dijangkau siapa pun dan hanya sekuat kode di baliknya; karena itulah RedAccess menemukan aplikasi yang menerima login dengan email apa pun.

Aturan saya: mulai dari jaringan privat, lalu tambahkan login perusahaan di atasnya jika peran memerlukan. Platform penerapan terkelola dengan login dan penyimpanan rahasia bawaan juga cocok bagi tim yang sudah membayarnya dan meninjau vendor.

Sisi server adalah bagian untuk meminta bantuan TI, dengan satu penanggung jawab yang disebutkan untuk server dan kunci. Alat berjalan pada VPS, yaitu server sewaan yang sepenuhnya dikendalikan tim, di bawah alat penerapan seperti Coolify atau Dokploy yang menjalankan aplikasi dari kode dan menyimpan variabel lingkungan, termasuk kunci platform.

Jaringan privat disediakan Tailscale yang lebih cepat disiapkan tetapi bergantung pada layanan koordinasinya sendiri (Headscale dapat menggantikannya), atau WireGuard yang sepenuhnya dihosting sendiri. Login perusahaan, yaitu single sign-on dengan akun perusahaan, memakai Authentik atau Keycloak; reverse proxy seperti Caddy atau Nginx Proxy Manager menambahkan HTTPS di bagian yang menghadap web.

Memindahkan Mesin Email ke Listmonk

Alih-alih kunci terbatas di platform saat ini, jalur lain menghilangkan kunci platform komersial dengan memindahkan daftar dan pengiriman ke pengelola daftar mandiri. Listmonk sejak v4.0.0 memungkinkan tiap alat memiliki pengguna API sendiri dengan peran daftar terbatas pada daftar yang disentuh alat itu.

Alat hanya baca mendapat akses lihat ke daftarnya tanpa pengiriman; campaigns:send dan tx:send untuk pesan transaksional hanya diberikan kepada alat kirim. Tiga izin sangat berisiko harus tetap di luar peran alat terbatas: lists:get_all dan lists:manage_all yang mengesampingkan peran per daftar, serta subscribers:sql_query. Dokumentasi peran dan izin Listmonk memperingatkan bahwa izin terakhir memungkinkan “kueri semua daftar dan pelanggan langsung dari basis data, melampaui izin daftar dan pelanggan individual”. Tinjau juga izin luas seperti subscribers:get_all, campaigns:get_all, dan campaigns:manage_all sebelum menyebut alat terbatas per daftar. Berikan setiap pengguna API hanya izin yang dibutuhkan tugas. Listmonk dibuat untuk kampanye, bukan otomatisasi bertahap (kapan Listmonk bukan alat yang tepat); Mautic menangani otomatisasi itu di server sejenis.

Imbalannya adalah pekerjaan berkelanjutan: tim mengurus autentikasi domain pengirim dengan SPF, DKIM, dan DMARC, relay SMTP untuk pengantaran, patch, cadangan, dan keterkiriman. Jika daftar kecil, tak ada yang bisa bertanggung jawab atas server, atau reputasi pengiriman serta otomatisasi platform lama menopang pekerjaan tim, bertahan di platform dengan kunci terbatas lebih tepat.

Kedua jalur perlu server dengan penanggung jawab, menjalankan alat penerapan dan jaringan privat; jalur mandiri juga perlu Listmonk serta relay SMTP. Linux VPS kami memberi akses root, dan Listmonk, Mautic, Tailscale, WireGuard, serta Authentik diterapkan sebagai aplikasi sekali klik. TI dapat memakai waktunya untuk konfigurasi dan tinjauan alih-alih instalasi; menjaga patch tetap menjadi tanggung jawab tim.

Lokasi mencakup Frankfurt dan Amsterdam di Uni Eropa, London di Inggris, serta beberapa kota AS. Pilihan menentukan lokasi alat dan setiap salinan daftar, termasuk daftar itu sendiri pada Listmonk. Lokasi adalah masukan untuk pembicaraan dengan DPO, bukan pengganti pembicaraan, dan tidak dengan sendirinya membuat alat patuh.

Persetujuan dan Aturan Antispam untuk Email Pemasaran

GDPR untuk Daftar Pelanggan Email

GDPR tidak mewajibkan persetujuan sebagai dasar pemrosesan pemasaran langsung: Pertimbangan 47 menyatakan pemrosesan itu “dapat dianggap dilakukan untuk kepentingan yang sah”. Jika pemasaran memakai persetujuan, Pasal 7 mengharuskan perusahaan “mampu menunjukkan” bahwa setiap orang menyetujui dan membuat pencabutan semudah pemberian persetujuan. Itulah peran sumber dan tanggal-waktu persetujuan di platform email.

Aturan lebih ketat ada pada Pasal 21 GDPR. Apa pun dasarnya, seseorang dapat menolak pemasaran langsung kapan pun, termasuk pemrofilan terkait; setelah itu “data pribadi tidak boleh lagi diproses untuk tujuan tersebut”. Untuk pemasaran tidak ada uji penyeimbangan, berbeda dari penolakan lain pada pasal yang sama. Default teraman alat ini adalah memperlakukan penolakan pemasaran langsung umum sebagai berlaku di seluruh pemakaian data orang tersebut untuk pemasaran: daftar kirim, segmen alat, dan audiens iklan. Penghentian khusus saluran mungkin lebih sempit, sehingga perusahaan harus menetapkan aturan preferensi bersama pemimpin privasi dan menghormati tiap permintaan secara tepat.

Daftar bocor atau salah diubah dapat merupakan pelanggaran data pribadi. Pasal 33 mewajibkan pemberitahuan kepada otoritas pengawas, yaitu regulator perlindungan data nasional, tanpa penundaan tak semestinya dan jika memungkinkan dalam 72 jam sejak mengetahuinya, kecuali pelanggaran itu kecil kemungkinannya menimbulkan risiko bagi orang. Di Inggris, hukum setara adalah UK GDPR, ditegakkan ICO.

Hukum Pengiriman: ePrivacy dan PECR, CAN-SPAM dan CASL

Aturan ePrivacy Uni Eropa dan PECR Inggris membutuhkan persetujuan sebelumnya untuk email pemasaran kepada individu, dengan soft opt-in terbatas bagi pelanggan lama. Inggris juga memiliki soft opt-in terpisah untuk tujuan amal dengan syarat khusus; artikel ini berfokus pada pemasaran komersial. CASL Kanada membutuhkan persetujuan tegas atau tersirat. CAN-SPAM AS tidak membutuhkan persetujuan pengiriman, tetapi mewajibkan opt-out yang berfungsi dan dipenuhi dalam 10 hari kerja, serta rincian pengirim akurat dan alamat pos pada setiap pesan.

Soft opt-in dalam Pasal 13 Direktif ePrivacy mencakup rincian kontak yang diperoleh saat penjualan untuk produk serupa milik sendiri, dengan kesempatan menolak gratis saat pengumpulan dan setiap pesan. Versi Inggris adalah Peraturan 22 PECR, dijelaskan dalam panduan pemasaran email ICO. Pasal 13 juga melarang email pemasaran yang menyamarkan pengirim atau tidak memiliki alamat valid untuk permintaan penolakan; Peraturan 23 PECR melakukan hal yang sama di Inggris.

Angka CAN-SPAM berasal dari panduan CAN-SPAM FTC, yang juga menyatakan alamat opt-out tidak boleh dijual atau dialihkan, kecuali kepada perusahaan yang disewa untuk membantu kepatuhan CAN-SPAM. Aturan CASL ada di Bagian 6 CASL dan Bagian 11, serta sanksinya dalam ikhtisar CASL ISED.

Pertanyaan yang Sering Diajukan

Apakah GDPR Berlaku pada Alat Newsletter yang Saya Buat Sendiri?

Jawabannya ditentukan tempat perusahaan beroperasi dan data siapa yang disimpan alat, bukan cara alat dibuat. Menurut Pasal 3, GDPR berlaku bagi perusahaan yang didirikan di Uni Eropa serta perusahaan di luar yang menawarkan barang atau jasa kepada orang di Uni Eropa atau memantau perilaku mereka di sana. Apakah perusahaan tertentu tercakup adalah pertanyaan bagi DPO-nya.

Apa yang Terjadi jika Kunci API Klaviyo Kami Bocor?

Pemegang kunci Full Access dapat mengubah daftar; kunci Read-Only hanya mengizinkan melihat. Buat pengganti dengan cakupan yang dipakai alat saja karena Klaviyo tidak bisa menambah cakupan ke kunci lama kemudian, jadi pilih sekarang; cabut kunci bocor segera, alihkan alat ke pengganti, dan periksa ekspor atau perubahan daftar yang tidak dilakukan siapa pun. Jika daftar mungkin dibaca, perlakukan sebagai kemungkinan pelanggaran GDPR.

Apakah Daftar Email yang Di-hash Tetap Data Pribadi?

Menurut GDPR, ya jika dapat dikaitkan kembali ke seseorang. Pertimbangan 26 memperlakukan data berpseudonim yang “dapat dikaitkan ke orang perseorangan dengan informasi tambahan” sebagai informasi tentang orang yang dapat diidentifikasi. Menurut pemahaman saya, pencocokan iklan justru bekerja karena alasan itu: platform dapat menghitung hash yang sama dari alamat yang sudah dimilikinya.

Apakah Email Pemasaran B2B Mengikuti Aturan yang Sama?

Tidak di semua tempat. Menurut FTC, CAN-SPAM tidak memberi pengecualian untuk email antarbisnis. Aturan email PECR mencakup individu, dan ICO memastikan Anda dapat mengirim email pemasaran kepada perusahaan. Untuk negara Uni Eropa dan Kanada, tanyakan kepada penasihat hukum.