آنچه Klaviyo Onsite Tracking جمع‌آوری می‌کند

فیچر Klaviyo Onsite (بارگذاری‌شده از static.klaviyo.com/onsite/js/klaviyo.js) یک صف جهانی _learnq را مقدار‌دهی کرده و بازدیدکنندگان را با کوکی مالکیتی Klaviyo به نام __kla_id شناسایی می‌کند. پس از نصب، به صورت خودکار رویدادهای pageview گزارش می‌کند، تعامل فرم را ضبط می‌کند، رویداد Active On Site را شلیک می‌کند که جریان Browse Abandonment Klaviyo را هدایت می‌کند و رفتار مرور ناشناس را در لحظه ورود بازدیدکننده یا ارسال فرم با آدرس ایمیل به پروفایل مشترک شناخته‌شده مرتبط می‌کند. رویدادهای بعدی — Viewed Product، Added to Cart، Started Checkout، Placed Order — از طریق همان infrastructure هویت شلیک می‌شوند و از همان attribution مبتنی بر کوکی استفاده می‌کنند.

برای تحلیل GDPR کوکی ضروری نیست، داده ترک کننده صفحه داده شخصی است زیرا به یک شناسه persistent مرتبط است و Klaviyo در ایالات متحده تاسیس شده است که انتقال را به Article 6 Framework حریم خصوصی داده‌های EU-US تابع می‌کند. هر سه شرط ردیابی Klaviyo Onsite را به‌طور محکم در منطقه «نیاز به رضایت قبلی» در EU، UK، EEA و برزیل تحت LGPD قرار می‌دهد. در کالیفرنیا، همان پردازش تحت حق opt-out-of-sharing-for-cross-context-behavioral-advertising CPRA قرار می‌گیرد که Klaviyo's sharing با مقصدهای رسانه پولی پایین‌دست را تریگر می‌کند.

سه سطح ردیابی که باید آن‌ها را دروازه‌دار کنید

نصب Klaviyo یک سطح ردیابی نیست، سه سطح است و باید آن‌ها را در ادغام CMP به صورت جداگانه درمان کنید.

اسکریپت ردیابی Onsite

این ردیاب رفتاری اصلی است — اسکریپتی که __kla_id را تنظیم می‌کند و جریان رویداد فعال‌در‌سایت را هدایت می‌کند. این سطحی است که اکثر تیم‌ها به یاد می‌آورند دروازه‌دار کنند و یکی از بیشترین سطوح regulators برای بازرسی قابل مشاهده است. به صورت پیش‌فرض آن را مسدود کنید و فقط وقتی بازدیدکننده دسته بازاریابی را قبول کند بارگذاری کنید.

Klaviyo Forms و popup های ثبت‌نام

Klaviyo Forms کتابخانه جداگانه‌ای است که ایمیل و popup های ثبت‌نام SMS، فرم‌های embedded و unlock های محتوای دروازه‌دار را تقویت می‌کند. در همان domain میزبانی می‌شود اما به عنوان اسکریپت جداگانه بارگذاری می‌شود. Forms می‌تواند رویدادهای impression و submission را مستقل از ردیاب Onsite اصلی شلیک کند، بنابراین فقط دروازه‌دار کردن Onsite در حالی که Forms را بارگذاری رها می‌کنید یک الگوی compliance جزئی رایج است که هنوز هم داده‌های شناسایی‌کننده را نشت می‌کند.

جمع‌آوری opt-in SMS

ثبت‌نام‌های SMS نیاز رضایت خود را تحت TCPA در ایالات متحده و تحت قوانین خاص‌بخش در EU دارند و فرم‌های SMS Klaviyo شماره‌های تلفن را همراه با رضایت checkbox-confirmed جمع‌آوری می‌کنند. رضایتی که در اینجا جمع‌آوری می‌شود برای پیام‌رسانی SMS خود است، جداگانه از cookie consent. یک stack به‌درستی پیکربندی‌شده هر دو را ثبت می‌کند: cookie consent در CMP، SMS consent در پروفایل مشترک Klaviyo.

کنترل‌های حریم خصوصی Klaviyo بومی

Klaviyo چندین primitive حریم خصوصی بومی را نمایش می‌دهد. مانند اکثر پلتفرم‌های بازاریابی فرض می‌کنند که یک تصمیم رضایت وجود دارد و درحال انتقال است. آن‌ها خود رضایت را جمع‌آوری نمی‌کنند.

خاصیت consent در identify calls

وقتی شما klaviyo.identify() یا klaviyo.track() را فراخوانی می‌کنید می‌توانید payload رضایت را اتصال دهید که مبنای حقوقی برای ارتباطات بازاریابی را ثبت می‌کند. این primitive درست برای انتقال تصمیم CMP به پروفایل مشترک Klaviyo است.

فیلدهای consent در سطح پروفایل

پروفایل مشترک دارای فیلدهای dedicated برای email consent، SMS consent و consent source است. به‌روزرسانی این فیلدها به موتور segmentation Klaviyo منتقل می‌شود بنابراین جریان‌ها وضعیت ثبت‌شده را مانند کنند.

پنل تنظیمات Privacy & Consent

رابط کاربری admin Klaviyo دارای بخش Privacy & Consent است که برخی از رفتارهای پیش‌فرض را کنترل می‌کند — برای مثال آیا رویداد Active On Site برای بازدیدکنندگانی بدون رضایت ثبت‌شده شلیک می‌شود. پیش‌فرض permissive است؛ محکم کردن این تنظیمات یک لایه مفید belt-and-suspenders در بالای دروازه‌بندی سطح CMP است.

ادغام CMP مرحله به مرحله

معماری قابل‌اعتماد این است که تمام سه سطح ردیابی Klaviyo را پشت CMP دروازه‌دار کنید و از خصوصیات consent در identify و track calls Klaviyo برای نگاه‌داشتن رکورد‌های مشترک پلتفرم هماهنگ با وضعیت رضایت ثبت‌شده استفاده کنید.

1. فیچر Onsite پیش‌فرض را از head حذف کنید

Klaviyo یک فیچر یک‌خطی فراهم می‌کند که نصب‌کنندگان معمولاً آن را در head سند paste می‌کنند. آن را حذف کنید. آن را با یک عنصر placeholder script جایگزین کنید که attribute type آن text/plain است و attribute data-category آن آن را به عنوان بازاریابی شناسایی می‌کند. CMP شما type را به text/javascript دوباره می‌نویسد وقتی بازدیدکننده دسته بازاریابی را قبول کند.

2. بارگذاری Klaviyo Forms را به تعویق بیندازید

کتابخانه Forms مستقل از Onsite بارگذاری می‌شود. همان الگوی placeholder را برای عنصر script آن اعمال کنید بنابراین قبل از رضایت شروع نشود. پس از اعطای رضایت هر دو Onsite و Forms می‌توانند با هم شروع شوند؛ رویدادهای queue‌شده به صورت خودکار خالی می‌شوند.

3. SMS consent را از cookie consent جدا کنید

جمع‌آوری opt-in SMS از طریق Klaviyo Forms انجام می‌شود اما رضایت جمع‌آوری‌شده (checkbox صریح برای بازاریابی SMS) یک artifact حقوقی جداگانه از cookie consent است. بنر CMP تصمیم cookie را ثبت می‌کند؛ checkbox فرم تصمیم SMS را ثبت می‌کند. آن‌ها را bundle نکنید — bundled consent تحت هر دو GDPR و TCPA نامعتبر است.

4. رضایت را به پروفایل Klaviyo منتقل کنید

وقتی یک مشترک شناخته‌شده رضایت را در سایت شما قبول یا لغو می‌کند CMP باید Klaviyo API را فراخوانی کند تا فیلدهای consent پروفایل را به‌روزرسانی کند. Klaviyo Profiles API از یک فراخوانی partial-update پشتیبانی می‌کند که email consent، SMS consent و consent timestamp را می‌نویسد بدون بقیه پروفایل overwrite کردن. اکثر CMPهای modern دارای connector Klaviyo هستند که این end-to-end را مدیریت می‌کند.

5. اگر Google tags را در کنار خود اجرا می‌کنید Consent Mode v2 را سیم‌کشی کنید

اکثر فروشگاه‌های Klaviyo-using نیز Google Ads و GA4 را اجرا می‌کنند. CMP شما باید سیگنال‌های v2 — ad_storage، analytics_storage، ad_user_data، ad_personalization — را در dataLayer منتشر کند قبل از اینکه هر Google tag شلیک شود. Klaviyo به صورت بومی این سیگنال‌ها را مصرف نمی‌کند اما Google می‌کند و یک عدم تطابق بین Klaviyo و Google به عنوان gap کاهش‌یافته قابل‌اندازه‌گیری در گزارش‌دهی attribution ظاهر می‌شود.

pitfalls رایج

چهار اشتباه ادغام به صورت مکرر در بازرسی‌های Klaviyo deployment ظاهر می‌شود.

Forms را به عنوان "فقط popup" درمان کردن

برخی تیم‌ها Onsite را تحت بازاریابی دروازه‌دار می‌کنند اما Forms را در initial render بارگذاری رها می‌کنند به این دلیل که "popup فقط یک عنصر UI است". کتابخانه Forms برای هر popup که نمایش داده می‌شود impression events را به Klaviyo شلیک می‌کند که داده رفتاری شناسایی‌کننده است که به یک vendor ad-tech US منتقل می‌شود — الگوی دقیقی که CMP باید جلوگیری کند.

bundling cookie و SMS consent

یک checkbox واحد که می‌گوید "من با کوکی‌ها و دریافت ایمیل SMS بازاریابی موافقت می‌کنم" برای هر دو نامعتبر است. Cookie consent باید مختص به کوکی‌ها باشد؛ SMS consent باید مختص به SMS باشد. کنترل‌های جداگانه استفاده کنید.

اجازه دادن به connectors paid-media third-party برای شلیک بر روی پروفایل‌های لغوشده

Klaviyo می‌تواند مخاطبین را به Google Ads، Meta، TikTok و سایر ad networks از طریق ادغام‌های خود push کند. اگر یک مشترک رضایت را لغو کند audience push نیاز دارد آن‌ها را drop کند — نه فقط متوقف کردن افزودن آن‌ها. تنظیمات audience-sync Klaviyo را پیکربندی کنید تا تغییرات consent-state را در real time مانند کند، نه فقط در initial sync.

فراموشی سؤال داده‌های تاریخی

وقتی بازدیدکننده رضایت را برای اولین بار قبول می‌کند stack شما نباید رفتار ناشناس pre-consent خود را به retroactively به پروفایل جدید مرتبط کند. CMP و Klaviyo باید موافق باشند که داده بروز pre-consent ناشناس است و نه داده شخصی مرتبط با پروفایل اکنون-شناخته‌شده. برخی جریان‌های Klaviyo این association را به صورت پیش‌فرض فرض می‌کنند — trigger جریان‌های مربوطه را بررسی کنید.

چک لیست بازرسی

شش سؤال concrete برای پاسخ برای هر Klaviyo deployment ترافیک EU، UK، برزیل یا کالیفرنیا را لمس کنید.

• آیا Onsite برای رضایت منتظر است؟ storefront را در یک پنجره خصوصی با حفاظت tracking strict باز کنید و تأیید کنید هیچ درخواست static.klaviyo.com قبل از پذیرش بنر شلیک نمی‌شود.
• آیا Forms برای رضایت منتظر است؟ تأیید کنید که popup impression events قبل از پذیرش دسته بازاریابی شلیک نمی‌شوند.
• آیا cookie consent و SMS consent جداگانه هستند؟ تأیید کنید که بنر cookie همچنین SMS consent را جمع‌آوری نمی‌کند و آن SMS opt-in فرم‌ها checkbox صریح خود را ثبت می‌کنند.
• آیا پروفایل Klaviyo وضعیت CMP را منعکس می‌کند؟ تأیید کنید که CMP تصمیمات رضایت را از طریق Klaviyo API به فیلدهای consent پروفایل می‌نویسد.
• آیا audience syncs لغوها را مانند می‌کنند؟ تأیید کنید که لغو رضایت مشترک را از downstream paid-media audiences حذف می‌کند نه فقط از syncs آینده.
• آیا رفتار pre-consent ناشناس نگاه‌داشته می‌شود؟ تأیید کنید که flow triggers رفتار pre-consent را به retroactively پروفایل‌های نو-شناخته‌شده مرتبط نمی‌کنند.

جایی که Klaviyo در Stack Consent-First قرار می‌گیرد

Klaviyo در تقاطع attribution تجارت الکترونیکی و ارتباطات بازاریابی direct است که بدان معنی است که هم cookie-consent regime (GDPR/ePrivacy، CCPA/CPRA) و هم marketing-communications regime (CAN-SPAM، TCPA، GDPR Article 6/7 برای پیام‌رسانی) را لمس می‌کند. معماری درست این دو سطح consent جداگانه را درمان می‌کند — هر دو از طریق یک CMP واحد که مالک source of truth است مسیریابی می‌شوند و با فیلدهای native consent Klaviyo از طریق API هماهنگ نگاه‌داشته می‌شوند. فروشگاه‌هایی که این را به‌درستی انجام می‌دهند رفتار abandoned-cart، browse-abandonment و segmentation را حفظ می‌کنند که Klaviyo را از نظر تجاری ارزشمند می‌کند در حالی که exposure بازرسی را به کسری از آنچه نصب پیش‌فرض حمل می‌کند کاهش می‌دهد. کار مهندسی مستقیم است؛ انضباط این است که تیم بازاریابی را به این اجازه ندادید که Forms را به عنوان معاف از همان قوانین ردیاب Onsite درمان کند.