Klaviyo Onsite Tracking เก็บรวบรวมข้อมูลอะไร

โค้ดสนิปเพ็ต Klaviyo Onsite (โหลดจาก static.klaviyo.com/onsite/js/klaviyo.js) จะเริ่มต้นคิวแบบ global ชื่อ _learnq และระบุตัวตนผู้เยี่ยมชมด้วยคุกกี้ที่เป็นของ Klaviyo ชื่อ __kla_id เมื่อติดตั้งแล้ว จะรายงานเหตุการณ์การเข้าชมหน้าเว็บโดยอัตโนมัติ บันทึกการโต้ตอบกับฟอร์ม เรียกใช้เหตุการณ์ Active On Site ที่ขับเคลื่อนโฟลว์ Browse Abandonment ของ Klaviyo และเชื่อมโยงพฤติกรรมการเรียกดูแบบไม่ระบุตัวตนกับโปรไฟล์สมาชิกที่รู้จักทันทีที่ผู้เยี่ยมชมเข้าสู่ระบบหรือส่งฟอร์มที่มีที่อยู่อีเมล เหตุการณ์ถัดไป — Viewed Product, Added to Cart, Started Checkout, Placed Order — ทำงานผ่านโครงสร้างพื้นฐานด้านตัวตนเดียวกันและสืบทอดการระบุแหล่งที่มาแบบอิงคุกกี้เดียวกัน

สำหรับการวิเคราะห์ตาม GDPR คุกกี้ดังกล่าวเป็นคุกกี้ที่ไม่จำเป็น ข้อมูลที่ออกจากหน้าเว็บเป็นข้อมูลส่วนบุคคลเพราะเชื่อมโยงกับตัวระบุถาวร และ Klaviyo มีที่ตั้งในสหรัฐอเมริกา ซึ่งทำให้การถ่ายโอนข้อมูลอยู่ภายใต้ EU-US Data Privacy Framework ทั้งสามเงื่อนไขผลักดันการติดตาม Klaviyo Onsite เข้าสู่เขต "ต้องได้รับความยินยอมล่วงหน้า" อย่างชัดเจนใน EU, UK, EEA และบราซิลภายใต้ LGPD ในแคลิฟอร์เนีย การประมวลผลเดียวกันอยู่ภายใต้สิทธิ์การเลือกไม่ร่วมแบ่งปันเพื่อการโฆษณาเชิงพฤติกรรมข้ามบริบทของ CPRA ซึ่งการแบ่งปันข้อมูลของ Klaviyo กับปลายทางสื่อแบบชำระเงินทำให้เกิดขึ้น

พื้นผิวการติดตามสามส่วนที่คุณต้องควบคุม

การติดตั้ง Klaviyo ไม่ใช่พื้นผิวการติดตามเดียว แต่เป็นสามส่วน และต้องได้รับการปฏิบัติแยกกันในการรวม CMP

สคริปต์ติดตาม Onsite

นี่คือตัวติดตามพฤติกรรมหลัก — สคริปต์ที่ตั้งค่า __kla_id และขับเคลื่อนสตรีมเหตุการณ์ active-on-site เป็นพื้นผิวที่ทีมส่วนใหญ่จำได้ว่าต้องควบคุมและเป็นสิ่งที่หน่วยงานกำกับดูแลเห็นได้ชัดที่สุดในการตรวจสอบ บล็อกโดยค่าเริ่มต้นและโหลดเฉพาะเมื่อผู้เยี่ยมชมยอมรับหมวดหมู่การตลาด

Klaviyo Forms และป็อปอัพลงทะเบียน

Klaviyo Forms เป็นไลบรารีแยกต่างหากที่ให้พลังแก่ป็อปอัพลงทะเบียนอีเมลและ SMS ฟอร์มฝังตัว และการปลดล็อกเนื้อหาที่ต้องลงทะเบียน ถูกโฮสต์บนโดเมนเดียวกันแต่โหลดเป็นสคริปต์แยก ฟอร์มสามารถเรียกใช้เหตุการณ์การแสดงผลและการส่งแบบอิสระจากตัวติดตาม Onsite หลัก ดังนั้นการควบคุมเฉพาะ Onsite ในขณะที่ปล่อย Forms โหลดอยู่ เป็นรูปแบบการปฏิบัติตามกฎหมายแบบบางส่วนที่พบบ่อย ซึ่งยังคงรั่วไหลข้อมูลที่ระบุตัวตนได้

การเก็บรวบรวมการเลือกรับ SMS

การลงทะเบียน SMS มีข้อกำหนดความยินยอมของตัวเองภายใต้ TCPA ในสหรัฐอเมริกาและภายใต้กฎเฉพาะรายภาคส่วนใน EU และฟอร์ม SMS ของ Klaviyo จะเก็บรวบรวมหมายเลขโทรศัพท์พร้อมกับความยินยอมที่ยืนยันด้วยช่องทำเครื่องหมาย ความยินยอมที่เก็บรวบรวมที่นี่เป็นสำหรับการส่งข้อความ SMS เอง แยกจากความยินยอมคุกกี้ ระบบที่กำหนดค่าอย่างถูกต้องจะบันทึกทั้งสองอย่าง: ความยินยอมคุกกี้ใน CMP และความยินยอม SMS ในโปรไฟล์สมาชิก Klaviyo

การควบคุมความเป็นส่วนตัวดั้งเดิมของ Klaviyo

Klaviyo เปิดเผยส่วนควบคุมความเป็นส่วนตัวดั้งเดิมหลายตัว เช่นเดียวกับแพลตฟอร์มการตลาดส่วนใหญ่ พวกเขาถือว่ามีการตัดสินใจเรื่องความยินยอมอยู่แล้วและกำลังถูกส่งเข้ามา พวกเขาไม่ได้เก็บรวบรวมความยินยอมด้วยตัวเอง

คุณสมบัติความยินยอมในการเรียก identify

เมื่อคุณเรียก klaviyo.identify() หรือ klaviyo.track() คุณสามารถแนบข้อมูลความยินยอมที่บันทึกฐานทางกฎหมายสำหรับการสื่อสารทางการตลาด นี่คือส่วนควบคุมที่ถูกต้องสำหรับการส่งผ่านการตัดสินใจของ CMP เข้าไปในโปรไฟล์สมาชิกของ Klaviyo

ฟิลด์ความยินยอมระดับโปรไฟล์

โปรไฟล์สมาชิกมีฟิลด์เฉพาะสำหรับความยินยอมอีเมล ความยินยอม SMS และแหล่งที่มาของความยินยอม การอัปเดตฟิลด์เหล่านี้จะส่งต่อไปยังเอ็นจิ้นการแบ่งกลุ่มของ Klaviyo เพื่อให้โฟลว์เคารพสถานะที่บันทึกไว้

แผงการตั้งค่า Privacy & Consent

UI แอดมินของ Klaviyo มีส่วน Privacy & Consent ที่ควบคุมพฤติกรรมเริ่มต้นบางอย่าง — ตัวอย่างเช่น เหตุการณ์ Active On Site จะเรียกใช้สำหรับผู้เยี่ยมชมที่ไม่มีความยินยอมที่บันทึกไว้หรือไม่ ค่าเริ่มต้นเป็นแบบอนุญาต การปรับให้เข้มงวดขึ้นเป็นเลเยอร์ป้องกันเพิ่มเติมที่มีประโยชน์บนการควบคุมระดับ CMP

การรวม CMP แบบทีละขั้นตอน

สถาปัตยกรรมที่เชื่อถือได้คือการควบคุมพื้นผิวการติดตาม Klaviyo ทั้งสามส่วนไว้เบื้องหลัง CMP และใช้คุณสมบัติความยินยอมในการเรียก Klaviyo identify และ track เพื่อให้บันทึกสมาชิกของแพลตฟอร์มซิงค์กับสถานะความยินยอมที่บันทึกไว้

1. ลบสนิปเพ็ต Onsite เริ่มต้นออกจาก head

Klaviyo ให้สนิปเพ็ตหนึ่งบรรทัดที่ผู้ติดตั้งมักจะวางใน document head ให้ลบออก แทนที่ด้วยอิลิเมนต์สคริปต์ตัวแทนที่แอตทริบิวต์ type เป็น text/plain และแอตทริบิวต์ data-category ระบุว่าเป็นการตลาด CMP ของคุณจะเขียน type กลับเป็น text/javascript เมื่อผู้เยี่ยมชมยอมรับหมวดหมู่การตลาด

2. เลื่อนการโหลด Klaviyo Forms

ไลบรารี Forms โหลดแยกจาก Onsite ใช้รูปแบบตัวแทนเดียวกันกับอิลิเมนต์สคริปต์ของมันเพื่อไม่ให้เริ่มต้นก่อนได้รับความยินยอม หลังจากได้รับความยินยอม ทั้ง Onsite และ Forms สามารถเริ่มต้นพร้อมกันได้ เหตุการณ์ที่อยู่ในคิวจะถูกส่งโดยอัตโนมัติ

3. แยกความยินยอม SMS ออกจากความยินยอมคุกกี้

การเก็บรวบรวมการเลือกรับ SMS ทำงานผ่าน Klaviyo Forms แต่ความยินยอมที่เก็บรวบรวม (ช่องทำเครื่องหมายที่ชัดเจนสำหรับการตลาด SMS) เป็นสิ่งประดิษฐ์ทางกฎหมายแยกจากความยินยอมคุกกี้ แบนเนอร์ CMP บันทึกการตัดสินใจเรื่องคุกกี้ ช่องทำเครื่องหมายในฟอร์มบันทึกการตัดสินใจเรื่อง SMS อย่ารวมเข้าด้วยกัน — ความยินยอมแบบรวมไม่ถูกต้องทั้งภายใต้ GDPR และ TCPA

4. ส่งต่อความยินยอมเข้าสู่โปรไฟล์ Klaviyo

เมื่อสมาชิกที่รู้จักยอมรับหรือเพิกถอนความยินยอมบนเว็บไซต์ของคุณ CMP ควรเรียก Klaviyo API เพื่ออัปเดตฟิลด์ความยินยอมของโปรไฟล์ Klaviyo Profiles API รองรับการเรียกอัปเดตบางส่วนที่เขียนความยินยอมอีเมล ความยินยอม SMS และเวลาประทับความยินยอมโดยไม่เขียนทับส่วนที่เหลือของโปรไฟล์ CMP สมัยใหม่ส่วนใหญ่มีตัวเชื่อมต่อ Klaviyo ที่จัดการเรื่องนี้ตั้งแต่ต้นจนจบ

5. เชื่อมต่อ Consent Mode v2 หากคุณใช้แท็ก Google ควบคู่กัน

ร้านค้าส่วนใหญ่ที่ใช้ Klaviyo ยังใช้ Google Ads และ GA4 ด้วย CMP ของคุณต้องเผยแพร่สัญญาณความยินยอม v2 — ad_storage, analytics_storage, ad_user_data, ad_personalization — เข้าสู่ dataLayer ก่อนที่แท็ก Google ใดๆ จะทำงาน Klaviyo ไม่ใช้สัญญาณเหล่านี้โดยตรง แต่ Google ใช้ และความไม่สอดคล้องกันระหว่าง Klaviyo และ Google จะแสดงเป็นช่องว่างรายได้ที่วัดได้ในรายงานการระบุแหล่งที่มา

ข้อผิดพลาดที่พบบ่อย

ข้อผิดพลาดในการรวมสี่ข้อที่ปรากฏซ้ำแล้วซ้ำเล่าในการตรวจสอบการติดตั้ง Klaviyo

ปฏิบัติต่อ Forms เหมือน "แค่ป็อปอัพ"

บางทีมควบคุม Onsite ภายใต้การตลาดแต่ปล่อย Forms โหลดตั้งแต่แรก โดยให้เหตุผลว่า "ป็อปอัพเป็นแค่องค์ประกอบ UI" ไลบรารี Forms ส่งเหตุการณ์การแสดงผลไปยัง Klaviyo สำหรับทุกป็อปอัพที่แสดง ซึ่งเป็นข้อมูลพฤติกรรมที่ระบุตัวตนได้ที่ถูกส่งต่อไปยังผู้ให้บริการเทคโนโลยีโฆษณาในสหรัฐอเมริกา — รูปแบบที่ CMP ควรจะป้องกันอย่างแท้จริง

การรวมความยินยอมคุกกี้และ SMS เข้าด้วยกัน

ช่องทำเครื่องหมายเดียวที่ระบุว่า "ฉันยินยอมให้ใช้คุกกี้และรับ SMS ทางการตลาด" ไม่ถูกต้องสำหรับทั้งสองอย่าง ความยินยอมคุกกี้ต้องเฉพาะเจาะจงสำหรับคุกกี้ ความยินยอม SMS ต้องเฉพาะเจาะจงสำหรับ SMS ใช้ตัวควบคุมแยกกัน

ปล่อยให้ตัวเชื่อมต่อสื่อแบบชำระเงินของบุคคลที่สามทำงานบนโปรไฟล์ที่เพิกถอนแล้ว

Klaviyo สามารถส่งกลุ่มเป้าหมายไปยัง Google Ads, Meta, TikTok และเครือข่ายโฆษณาอื่นๆ ผ่านการรวมของมัน หากสมาชิกเพิกถอนความยินยอม การส่งกลุ่มเป้าหมายต้องลบพวกเขาออก — ไม่ใช่แค่หยุดเพิ่มพวกเขา กำหนดค่าการตั้งค่าซิงค์กลุ่มเป้าหมายของ Klaviyo ให้เคารพการเปลี่ยนแปลงสถานะความยินยอมแบบเรียลไทม์ ไม่ใช่แค่ตอนซิงค์ครั้งแรก

ลืมคำถามเรื่องข้อมูลย้อนหลัง

เมื่อผู้เยี่ยมชมยอมรับความยินยอมเป็นครั้งแรก ระบบของคุณไม่ควรเชื่อมโยงพฤติกรรมที่ไม่ระบุตัวตนก่อนได้รับความยินยอมกับโปรไฟล์ใหม่ของพวกเขาย้อนหลัง CMP และ Klaviyo ควรเห็นตรงกันว่าข้อมูลการเรียกดูก่อนได้รับความยินยอมไม่ใช่ข้อมูลส่วนบุคคลที่เชื่อมโยงกับโปรไฟล์ที่ระบุตัวตนได้แล้ว โฟลว์ Klaviyo บางตัวถือว่ามีการเชื่อมโยงนี้โดยค่าเริ่มต้น — ตรวจสอบทริกเกอร์โฟลว์ที่เกี่ยวข้อง

รายการตรวจสอบการตรวจสอบ

คำถามที่เป็นรูปธรรมหกข้อที่ต้องตอบสำหรับการติดตั้ง Klaviyo ใดๆ ที่มีการเข้าชมจาก EU, UK, บราซิล หรือแคลิฟอร์เนีย

• Onsite รอความยินยอมหรือไม่? เปิดหน้าร้านในหน้าต่างส่วนตัวที่มีการป้องกันการติดตามแบบเข้มงวด และยืนยันว่าไม่มีคำขอ static.klaviyo.com ทำงานก่อนการยอมรับแบนเนอร์
• Forms รอความยินยอมหรือไม่? ยืนยันว่าเหตุการณ์การแสดงผลป็อปอัพไม่ทำงานก่อนที่หมวดหมู่การตลาดจะถูกยอมรับ
• ความยินยอมคุกกี้และความยินยอม SMS แยกกันหรือไม่? ยืนยันว่าแบนเนอร์คุกกี้ไม่ได้เก็บรวบรวมความยินยอม SMS ด้วย และฟอร์มเลือกรับ SMS บันทึกช่องทำเครื่องหมายที่ชัดเจนของตัวเอง
• โปรไฟล์ Klaviyo สะท้อนสถานะ CMP หรือไม่? ยืนยันว่า CMP เขียนการตัดสินใจเรื่องความยินยอมไปยังฟิลด์ความยินยอมของโปรไฟล์ผ่าน Klaviyo API
• การซิงค์กลุ่มเป้าหมายเคารพการเพิกถอนหรือไม่? ยืนยันว่าการเพิกถอนความยินยอมจะลบสมาชิกออกจากกลุ่มเป้าหมายสื่อแบบชำระเงินปลายทาง ไม่ใช่แค่จากการซิงค์ในอนาคต
• การเรียกดูก่อนได้รับความยินยอมถูกเก็บเป็นข้อมูลนิรนามหรือไม่? ยืนยันว่าทริกเกอร์โฟลว์ไม่เชื่อมโยงพฤติกรรมก่อนได้รับความยินยอมกับโปรไฟล์ที่เพิ่งระบุตัวตนได้ย้อนหลัง

Klaviyo เข้ากันได้อย่างไรในระบบที่ให้ความยินยอมมาก่อน

Klaviyo อยู่ที่จุดตัดของการระบุแหล่งที่มาอีคอมเมิร์ซและการสื่อสารทางการตลาดโดยตรง ซึ่งหมายความว่ามันสัมผัสทั้งระบอบความยินยอมคุกกี้ (GDPR/ePrivacy, CCPA/CPRA) และระบอบการสื่อสารทางการตลาด (CAN-SPAM, TCPA, GDPR มาตรา 6/7 สำหรับการส่งข้อความ) สถาปัตยกรรมที่ถูกต้องปฏิบัติต่อสิ่งเหล่านี้เป็นพื้นผิวความยินยอมสองส่วนที่แตกต่างกัน — ทั้งสองส่งผ่าน CMP เดียวที่เป็นแหล่งข้อมูลที่เชื่อถือได้ โดยฟิลด์ความยินยอมดั้งเดิมของ Klaviyo ถูกซิงค์ผ่าน API ร้านค้าที่ทำเรื่องนี้ถูกต้องจะรักษาพฤติกรรมตะกร้าที่ถูกทิ้ง การเรียกดูที่ถูกทิ้ง และการแบ่งกลุ่มที่ทำให้ Klaviyo มีคุณค่าทางธุรกิจ ในขณะที่ลดความเสี่ยงในการตรวจสอบให้เหลือเพียงส่วนน้อยเมื่อเทียบกับการติดตั้งแบบค่าเริ่มต้น งานด้านวิศวกรรมนั้นตรงไปตรงมา วินัยอยู่ที่การไม่ปล่อยให้ทีมการตลาดปฏิบัติต่อ Forms ว่ายกเว้นจากกฎเดียวกันกับตัวติดตาม Onsite