كيفية تتبع تحويلات التجارة الإلكترونية عبر المجالات والأجهزة والمتصفحات عند إجراء اختبار A / B؟

ما هو التتبع عبر البيئة؟

تحويل واحد ، نقاط اتصال متعددة!

هذا هو ما يدور حوله التتبع عبر البيئة.

يستخدم العملاء اليوم مجموعة متنوعة من نقاط الاتصال لإكمال مشتريات التجارة الإلكترونية. يمكنهم الوصول إلى الإنترنت من أجهزة متعددة وعرض الحملات التسويقية في بيئة واحدة قبل التحويل على أخرى ، وربما يبدأون على جهاز كمبيوتر محمول ونطاق "أ" أثناء تصفحهم حتى تحديد المنتج الأكثر ملاءمة لهم ، ثم الانتقال إلى الهواتف الذكية ، وغالبًا ما يتم تبديل المتصفحات بينهما ، وأخيراً الشراء على النطاق "B".

نتيجة لهذا الاتجاه ، يمتد عدد متزايد من مسارات التحويل عبر مجالات وأجهزة ومتصفحات ويب متعددة.

يمكن أن تكون تفاعلات زوار الموقع عادةً من نوعين:

• بيئة واحدة: عندما تبدأ الرحلة إلى التحويل وتنتهي على نفس الجهاز أو المتصفح أو المجال.
• عبر البيئة: عندما ينقر زوار موقع الويب من جهاز أو متصفح أو مجال واحد ولكنهم يقومون بالتحويل في بيئة مختلفة.

إليك صيغة مبسطة لفهم هذه المصطلحات:

نظرًا لكون التفاعلات عبر البيئة أكثر شيوعًا ، يمكن أن يمثل تتبع التحويلات وإسنادها تحديًا. لذا ، كيف يمكننا تتبع تحويلات التجارة الإلكترونية هذه عندما تتغير البيئة لتقديم تجربة مخصصة؟ أولاً ، نحتاج إلى فهم الخصائص التي يمكن أن تتغير من البيئة ، ثم تحديد الطرق المختلفة لتتبع تلك التحويلات.

دعنا نفصل الأنواع المختلفة من التتبع التي يمكن أن تحدث في مسار التجارة الإلكترونية متعدد القنوات للتأكد من عدم تسلل أي عميل من خلال الثغرات:

التتبع عبر المجالات

يعد التتبع عبر النطاقات طريقة لتحليل الزوار عبر نطاقات متعددة.

لماذا يعد التتبع عبر النطاقات مفهومًا مهمًا في اختبار A / B؟

يعد التتبع عبر النطاقات ميزة رائعة تسمح لك بإسناد التحويلات والسلوك إلى حملاتك حتى إذا كانت رحلة المستخدم تمتد عبر مجالات متعددة. بدون ذلك ، سيكون الإسناد مستحيلًا تقريبًا بالنسبة لأولئك منا الذين لديهم أكثر من مجال واحد (مثل المواقع التي تحتوي على نطاق منفصل للتسوق أو الخروج).

فيما يلي بعض مقاييس التحويل التي يمكن التقاطها عبر النطاقات:

• التحويلات
• أحداث التحويل
• تحويلات نشاط النقر
• تحويلات نشاط العرض
• إجمالي التحويلات
• أحداث تحويل نشاط النقر
• أحداث تحويل نشاط العرض
• إجمالي أحداث التحويل
• إجمالي الإيرادات

التتبع عبر النطاقات مع ملفات تعريف ارتباط الطرف الثالث

يعتمد الشكل الأكثر شيوعًا للتتبع عبر النطاقات على ملفات تعريف ارتباط الطرف الثالث.

تستخدم مواقع الويب ملفات تعريف ارتباط الطرف الأول لتخزين معلومات حول الزائر وجلسته وعادة ما يكون لها السمات التالية:

• اسم ملف تعريف الارتباط : اسم ملف تعريف الارتباط.
• مجال ملف تعريف الارتباط : المجال الذي تم إعداد ملف تعريف الارتباط عليه.
• مسار ملف تعريف الارتباط: المسار الذي تم إعداد ملف تعريف الارتباط عليه. تم تعيين هذا كدليل جذر للمجال '/'.
• انتهاء صلاحية ملف تعريف الارتباط: الوقت بالثواني الذي تنتهي فيه صلاحية ملف تعريف الارتباط.

الآن ، نظرًا لأن هذه ملفات تعريف ارتباط الطرف الأول ، لا يمكنهم مشاركة المعلومات مع المجالات الأخرى. هذا هو المكان الذي يلعب فيه التتبع عبر النطاقات. في هذه الحالة ، نحتاج إلى توجيهه لمشاركة قيم النطاق A ملف تعريف الارتباط مع ملف تعريف الارتباط الخاص بالمجال B ، وتحويل ملف تعريف ارتباط الطرف الأول إلى ملف تعريف ارتباط تابع لجهة خارجية.

ما سيفعله التتبع عبر النطاقات هو إلحاق قيم ملف تعريف الارتباط للنطاق بعناوين URL حيث يتغير النطاق باستخدام سلسلة استعلام افتراضيًا. يمكن أيضًا تغيير هذا إلى جزء عنوان URL إذا لم تكن من محبي سلاسل الاستعلام. سيتعرف المجال B على هذه المعلمات المضافة في عناوين URL هذه للتأكد من أن ملف تعريف الارتباط يتبنى هذه القيم.

دعنا نرى مثالاً لما سيبدو عليه هذا.

لنفترض أنك تريد استئجار سيارة عبر الإنترنت. للتحقق من الخيارات المختلفة ، من المحتمل أن تنتقل إلى أحد مواقع تأجير السيارات (سنستخدم car.com في هذا المثال). نظرًا لأن الموقع يحتوي على العديد من المجالات الفرعية (car.com ، و payment.car.com ، و pickup.car.com ، وما إلى ذلك) ومجال جهة خارجية لتلقي المدفوعات (secure.booking.com) ، ستكون رحلة المستخدم الخاصة بك عبر- نطاق.

باستخدام التتبع عبر النطاقات ، يمكن لفريق Car.com اكتشاف تبديل مستخدم من نطاق فرعي إلى آخر وتخصيص تجربته بالكامل مع المنتجات أو الخدمات الأكثر صلة عبر نطاقات فرعية مختلفة.

التتبع عبر المجالات مع التخزين المحلي

ومع ذلك ، هناك عيب كبير عند استخدام ملفات تعريف الارتباط في التتبع عبر النطاقات: تخزينها المحدود.

يمكن أن تحتوي ملفات تعريف الارتباط على بيانات أقل بكثير من التخزين المحلي: يقتصر تخزين ملفات تعريف الارتباط على 4096 بايت بينما تبلغ مساحة التخزين المحلية 5 ميجابايت لكل مجال. لذلك إذا كنت تستخدم ملفات تعريف الارتباط ، فكلما زاد عدد البيانات التي تريد تخزينها في متصفحات الزوار ، زاد عدد ملفات تعريف الارتباط التي ستحتاج إلى إنشائها.

مشكلة أخرى مع ملفات تعريف الارتباط هي أنها تبطئ موقع الويب الخاص بك ، مما يجعل تجربة المستخدم دون المستوى الأمثل. مع كل طلب HTTP ، يتم إرسال ملفات تعريف الارتباط إلى الخادم. إذا كانت لديك رحلة عبر المجالات ، فسيصبح هذا أسوأ. سيتصفح الزوار ذهابًا وإيابًا بين المجالات المختلفة ، مما يزيد من طلبات HTTP وعدد ملفات تعريف الارتباط في متصفحهم.

للأسباب المذكورة أعلاه ، تستخدم بعض المواقع التخزين المحلي بدلاً من تخزين ملفات تعريف الارتباط. ما يعنيه هذا هو أنك تستضيف بشكل أساسي الملف على المجال A وتستخدم iframe على المجال B الذي يقوم بتحميل الملف من المجال A. وبهذه الطريقة تشارك بيانات الزائر بين المجالين كما لو كان مجالًا واحدًا:

ملف 1.html:

 <html>
<head />
<iframe src = 'http: //127.0.0.1/test.html' />
</html>

ملف 2.html:

 <html>
<head />
<script>
console.log (localStorage) ؛
localStorage.setItem ('اختبار'، '123') ،
</script>
</html>

المفاهيم الخاطئة حول التتبع عبر المجالات

غالبًا ما يكون التتبع عبر النطاقات ممارسة يساء فهمها. فيما يلي أهم ثلاثة مفاهيم خاطئة قد تفاجئك!

الأسطورة رقم 1. أنت بحاجة إلى التتبع عبر المجالات لتتبع المستخدمين عبر المجالات الفرعية

يعتقد العديد من خبراء CRO أنهم بحاجة إلى تمكين التتبع عبر النطاقات لتتبع الزوار عبر النطاقات الفرعية. هذا ليس صحيحا. يمكن مشاركة ملفات تعريف الارتباط بين المجالات الفرعية والمجال الرئيسي.

لذلك ، على سبيل المثال ، إذا تم تعيين ملف تعريف ارتباط على www.convert.com ، فيمكن أيضًا الوصول إليه عن طريق blog.convert.com دون تمكين التتبع عبر النطاقات.

الأسطورة رقم 2. هناك حاجة إلى التتبع عبر المجالات لبوابات الدفع

الجزء المربك التالي حول التتبع عبر النطاقات هو أنك تحتاج إلى إعداده لبوابات الدفع (على سبيل المثال ، PayPal.com).

ومع ذلك ، لا يكون التتبع عبر النطاقات ممكنًا إلا إذا كنت تتحكم في كلا النطاقين.

في معظم الأوقات ، لا تسمح لك بوابات الدفع بوضع شفرة التتبع الخاصة بك على صفحات الويب الخاصة بهم لأسباب أمنية (المزيد حول هذا أدناه).

الأسطورة رقم 3. هناك حاجة إلى التتبع عبر النطاقات عند وجود مجالات متعددة

الاعتقاد الخاطئ الآخر هو أنك تحتاج إلى تتبع عبر النطاقات كلما كنت تستخدم مجالات مختلفة. هذا صحيح فقط إذا كنت تريد أن ترى نفس المستخدم يتنقل عبر مواقع الويب وأن تنسب التحويلات إلى مصادر حركة المرور. في هذه الحالة ، ستحتاج إلى التتبع عبر النطاقات.

ومع ذلك ، إذا كنت تريد أن ترى المجال A كمصدر حركة مرور إلى المجال B ولا تهتم بمصادر المرور التي وصل منها الأشخاص إلى المجال A ، فلن تحتاج إلى تتبع عبر النطاقات.

التتبع عبر الأجهزة

في الوقت الحاضر ، يمتلك الأشخاص أجهزة متعددة. هذا يعني أن الزوار قد يتفاعلون مع علامتك التجارية (على سبيل المثال ، النقر على إعلانات Google الخاصة بك) على أحد الأجهزة ، ثم التبديل إلى جهاز آخر ومواصلة التحقق من منتجاتك. بفضل تقارير التحويل عبر الأجهزة ، يمكن للمسوقين التحقق من فعالية حملاتهم عبر جميع الأجهزة (الجهاز اللوحي والجوال وسطح المكتب) ، بغض النظر عن الجهاز الذي يقوم المستخدم بالتحويل عليه بالفعل.

تعمل التقارير عبر الأجهزة على ربط ملفات تعريف الارتباط (للويب) ومعرفات الجهاز (لتطبيقات الأجهزة المحمولة) وبيانات تسجيل الدخول المجمعة معًا لتحديد مستخدم عبر أجهزة مختلفة. يتيح ذلك لمالكي مواقع الويب تحديد المسار الذي يسلكه المستخدم ، من التفاعل الأول مع العلامة التجارية أو مشاهدة الإعلان إلى نقطة التحويل.

يساعد المسوقين في تحديد زوار موقع ويب معينين ، حتى لو دخلوا مسار التحويل باستخدام طرق مختلفة:

هناك طريقتان أساسيتان للتتبع عبر الأجهزة.

بطريقة واحدة ، يتم تتبع زوار الموقع من خلال معرفات الزوار الثابتة. تعتمد الطريقة الأخرى على سلوك المستخدم بمعرف الجهاز.

التتبع عبر الأجهزة بمعرفات الزائر (حتمي)

غالبًا ما تُستخدم هذه الطريقة عندما يقوم المستخدمون بالتسجيل من خلال رسالة إخبارية أو تسجيل الدخول. تقوم الشبكات الاجتماعية مثل Facebook أو Instagram أو TikTok أو Twitter بالتتبع عبر الأجهزة عن طريق تعيين معرفات الزائر.

هذه الطريقة مناسبة للمواقع التي لديها زوار مسجلين. بمجرد تمييز الزائر بمعرف فريد ، يتم إخطار نظام التتبع في كل مرة يسجل فيها الزائر الدخول. إذا كان الزائر نفسه يستخدم جهازًا آخر لاحقًا ، دعنا نقول جهازًا لوحيًا ، ويفتح موقع الويب المعني كتطبيق ويسجل الدخول ، يمكن تتبعها بدقة.

هذه الطريقة ، المعروفة أيضًا باسم الحتمية ، دقيقة للغاية (حوالي 100٪) ويمكن استخدامها لتشغيل حملات دقيقة تستهدف مستخدمين محددين.

التتبع عبر الأجهزة استنادًا إلى معرف الجهاز (احتمالي)

تعمل الطريقة الثانية للتتبع عبر الأجهزة أيضًا عن طريق وضع علامات على المستخدمين ، ولكن هذه المرة فقط لا يحتاجون إلى التسجيل. تعتمد هذه الطريقة على العديد من السمات التي يتم جمعها من عناوين IP أو الأجهزة أو المتصفحات أو التطبيقات التي يتصفحها الزائر ويتم دمجها في ملف تعريف المستخدم. عيب هذه الطريقة أنها ليست دقيقة كما هو الحال عند استخدام معرف زائر.

يشار إليه أيضًا باسم الاستهداف الاحتمالي . كما يوحي الاسم ، يتحدث عن احتمالية أن يكون A هو المستخدم الذي يمتلك جهاز سطح مكتب (جهاز X) وهاتف ذكي (جهاز Y). لذلك ، لإجراء التتبع ، تم تصميم خوارزميات بكمية هائلة من السمات ، والتي تقوم بعد ذلك بتقسيم المستخدمين بناءً على سلوك مماثل عبر الأجهزة والمواقع الجغرافية وعناوين IP وأي سياق مشابه آخر. بالطبع لا يمكن أن تصل دقة هذا التتبع إلى 100٪ ، لكن 60-70٪ هدف جيد.

التتبع عبر المستعرضات

أخيرًا ، يسمح التتبع عبر المستعرضات لموقع الويب بتتبع المستخدم بين المتصفحات المختلفة ، بما في ذلك Chrome و Firefox و Microsoft Edge و Safari و Tor.

تسمى الطريقة الكامنة وراء التتبع عبر المستعرضات ببصمات المتصفح .

إنه يعمل عن طريق تحديد مجموعة من الخصائص الفريدة لأجهزة وبرامج الكمبيوتر واستخدام تلك المعلومات ، "بصمة" للنظام المعني.

قد لا تدرك ذلك ، ولكن يتم دمج كل شيء من التطبيقات المثبتة إلى إعدادات المستعرض الخاص بك لتشكيل ملف التعريف الفريد الخاص بك . تعتمد درجة قابلية التعرف على بصمة الإصبع هذه على خوارزمية كل متصفح.

لنفترض أنك تتصفح على Firefox ، وتشاهد إعلانًا ، وتقرر الانتقال إلى Chrome لشراء منتج لتجنب الاستهداف من خلال إعادة استهداف الحملات. ما لم تقم بتعطيل التتبع عبر المتصفحات من إعدادات المستعرض الخاص بك ، ستظل المتصفحات قادرة على استهدافك بالحملات.

متى تختار المواقع المعاملات على مجال / جهاز / متصفح مختلف؟

يعد التتبع عبر النطاقات مفيدًا بشكل خاص عندما يرغب مالكو المواقع في تتبع الجلسات التي تحدث عبر نطاقين أو نطاقات فرعية أو أكثر ومعالجة هذه الجلسات على أنها جلسة واحدة.

تمتد الجلسات عادةً عبر مجالات متعددة عندما:

1. يتم تعيين عملية الدفع على مجال مختلف (وهو أمر شائع جدًا عند استخدام عربة تسوق تابعة لجهة خارجية مثل Shopify) ،
2. يتم إجراء تحويل الهدف أو معاملة التجارة الإلكترونية على نطاق مختلف (وهو أمر شائع أيضًا في حالة مواقع الويب التابعة).

إليك سيناريو نموذجي حيث يكون التتبع عبر النطاقات منطقيًا: منصات التجارة الإلكترونية مع عربات تسوق تابعة لجهات خارجية.

في هذه الحالة ، قد يهبط المستخدم على الموقع الرئيسي لعرض منتج من حملة PPC. عندما يتوجه المستخدم إلى الخروج ، يتم نقله إلى عربة تسوق تابعة لجهة خارجية في مجال مختلف ، على سبيل المثال عبر Shopify ، لإكمال المعاملة.

بدون التتبع عبر النطاقات ، لن يتم ربط سلوك التسوق والدفع ولن يتم تتبع التحويلات عبر المجالات المختلفة. لذلك ، يحتاج أصحاب المتاجر عبر الإنترنت إلى ربط نطاقاتهم بطريقة ما. وإلا ، فسيتم إضافة التحويل إلى عربة التسوق التابعة لجهة خارجية ، وليس مصدر الزيارات الأصلي.

لذلك ، يتيح لك التتبع عبر النطاقات تتبع الزائر بشكل موثوق حتى بعد مغادرته موقعك.

فائدة أخرى لتنفيذ التتبع عبر النطاقات هي أنه يمكنك جمع البيانات من نطاقات مختلفة في تقرير واحد.

تُسهل مركزة بيانات المعاملات تحسينًا أفضل لأنها

• يدعم التحسينات المستمرة في عمليات صنع القرار ،
• يقوي تتبع أفضل للعمليات التجارية وتحسينها ، و
• يقلل من مخاطر المنظمة مع منع التأثير السلبي لعدم الدقة والتكرار.

وأخيرًا ، لا يتعين على مالكي المواقع أن يقتصروا على القيام بجميع الصفحات المقصودة قبل البيع على موقع المال الرئيسي الخاص بهم بعد الآن ، بسبب قيود التتبع. يمكن أن تتفرع إلى مواقع ويب متعددة من أجل مسار تسويق موقع ويب تسويقي أوسع وقابل للتتبع.

في عالم اليوم متعدد القنوات ، الطريقة التي يستخدم بها المستهلكون الأجهزة والمتصفحات تمتد عبر منصات مختلفة: قد يقرأون الأخبار الصباحية على أجهزتهم اللوحية على Firefox ، ويفحصون البريد الإلكتروني أثناء تنقلاتهم الصباحية على هواتفهم على Chrome ، ويستخدمون أجهزة الكمبيوتر المكتبية الخاصة بهم أثناء العمل. في الليل ، قد يتصفحون ساعاتهم الذكية لمتابعة أخبار اليوم.

هنا سيناريو نموذجي:

• يتصفح أحد المستخدمين موجز الأخبار على هاتفه وينقر على منشور حول منتجك. المستخدم مهتم ولكنه لا يقوم بالتسجيل على الفور.
• في وقت لاحق من ذلك الأسبوع ، قرر المستخدم التحقق من منتجك مرة أخرى ، ولكن هذه المرة يزور مجالك مباشرة من جهاز الكمبيوتر الخاص به من متصفح آخر. ثم يقرر المستخدم التسجيل.
• في غضون يومين ، يسجل المستخدم الدخول إلى تطبيقك من هاتفه.
• يجب ربط جميع محفوظات الاستعراض الخاصة بهم على الأجهزة والمتصفحات المذكورة أعلاه بحسابهم بشكل صحيح ويجب أن تُنسب هذه النقرة الأصلية من موجز الأخبار إلى التحويل بشكل صحيح.

يمكن أن تساعد هذه التقنية مالكي المواقع على فهم سلوك المستهلك والمسار متعدد القنوات للشراء بشكل أفضل. إنها تمكنهم من تقديم تجربة أفضل للعملاء وإنشاء استراتيجيات تسويق متعددة القنوات عالية الاستهداف عبر نقاط اتصال مختلفة. يساعد في الإجابة على أسئلة مثل:

• هل تصل حملات الدفع لكل نقرة (PPC) الخاصة بي إلى المستهلكين المثاليين في الوقت المناسب؟
• كيف يمكنني قياس الأجهزة التي تجلب أكبر عدد من التحويلات بشكل فعال لتحسين حملاتي ومكافأة هذا المصدر؟
• كيف يمكن تشغيل تجارب موقع الويب الخاص بي بسلاسة عبر الأجهزة والمتصفحات وتزويد عملائي بتجربة علامة تجارية متسقة؟
• كيف يمكنني الوصول إلى المستهلكين بغض النظر عن الجهاز الذي يستخدمونه ، ليس فقط لتحفيزهم على التفاعل مع علامتي التجارية ، ولكن أيضًا لجعلهم يعودون كعملاء متكررين؟

كيف تؤثر تغييرات الخصوصية على التتبع عبر البيئات؟

نظرًا لأن الإنترنت أصبح جزءًا لا يتجزأ من الحياة اليومية ، فمن المهم أن يشعر الناس بالأمان عند التصفح. للمساعدة في الحفاظ على خصوصية المعلومات الشخصية على مواقع الويب ، يقوم المزيد والمزيد من المتصفحات بوضع إجراءات منع التتبع في مكانها الصحيح. فيما يلي تفصيل لأحدث تغييرات منع التتبع وكيف يمكن أن تؤثر على التتبع عبر البيئة.

سنستعرض بإيجاز كل تحديث من التحديثات أدناه ، ولكن للحصول على وصف أكثر تفصيلاً لكل من التحديثات وكيف تعامل معها التحويل ، اقرأ كيف تغير التتبع وملفات تعريف الارتباط في عام 2019 وكيف تغير التتبع وملفات تعريف الارتباط في عام 2020.

ملفات تعريف ارتباط الطرف الثالث المحظورة في وضع التصفح المتخفي من Google

في وضع التصفح المتخفي ، لا يحفظ Google Chrome سجل تصفح المستخدم أو معلومات النموذج أو ملفات تعريف الارتباط للمتصفح. بدءًا من Chrome 83 ، يحظر المتصفح ملفات تعريف الارتباط للجهات الخارجية في وضع التصفح المتخفي افتراضيًا.

لا يزال بإمكان المستخدمين السماح بملفات تعريف الارتباط للجهات الخارجية لمواقع محددة ، ولكن أي طرق تتبع متقاطعة تعتمد على ملفات تعريف ارتباط الطرف الثالث تواجه الآن تحديات كبيرة لأنها بحاجة إلى تمكينها بواسطة زوار الموقع من إعدادات المتصفح الخاصة بهم.

منع التتبع الصارم في وضع InPrivate الخاص بـ Microsoft Edge

في Microsoft Edge 80 ، يسمح السلوك الافتراضي للمستخدمين بتحديد ما إذا كانوا يريدون حماية الوضع المتشدد أم لا أثناء استعراض InPrivate.

هذا يعني أنه إذا قام المستخدمون بتشغيل هذه الميزة ، فسيصبح التتبع المتقاطع مستحيلاً.

Mozilla Enhanced Tracking Protection (ETP) 2.0

منذ عام 2019 ، سيتم تشغيل الحماية المحسّنة للتتبع (ETP) لمستخدمي Firefox بشكل افتراضي ، وفي العام الماضي ، أضافت Mozilla طبقة أمان إضافية مع Enhanced Tracking Protection 2.0 حيث يحظرون تتبع إعادة التوجيه. يقوم ETP 2.0 بمسح ملفات تعريف الارتباط وبيانات الموقع من المواقع كل 24 ساعة ، باستثناء تلك المواقع التي يتفاعل معها المستخدمون بانتظام!

لذلك انسَ طرق التتبع المتقاطع التي تعتمد على ملفات تعريف الارتباط المحظورة بواسطة ETP.

منع التتبع الذكي في iOS 14 و iPad 14 و Safari 14

مع إصدار iOS 14 و iPad 14 و Safari 14 ، قامت Apple بتضمين ميزات خصوصية جديدة مثل تقرير الخصوصية حيث يمكن للمستخدمين الاطلاع على معلومات حول أجهزة التتبع المحظورة ، بالإضافة إلى ITP لجميع متصفحات الويب على أجهزة iOS (الإصدار 14 وما فوق) ، والتي منع الإحالة عبر التتبع.

هل يمكن لأدوات اختبار A / B تتبع تحويلات التجارة الإلكترونية والحفاظ على خصوصية المستخدم؟

تحد تحديثات التتبع والخصوصية الموضحة أعلاه من المعلومات التي يمكن تتبعها عبر بيئات متعددة ، ولكن الحفاظ على خصوصية المستخدم وتقديم تجربة مخصصة لا يستبعد أحدهما الآخر.

لا يجب أن يحدث جمع البيانات عبر البيئة بطريقة تطفلية تهدد ثقة عملائك أو تمنعهم من تحقيق أقصى استفادة من موقعهم على الويب - هناك طريقة يمكنك القيام بها مع احترام العالمين!

يمكن لأدوات اختبار A / B تقديم حلول لمساعدة شركتك على معرفة ما يريده المستخدمون ومنحهم تجربة رائعة عبر الإنترنت ، مع احترام الخصوصية في نفس الوقت.

دعنا ننتقل إلى بعض أدوات اختبار A / B الأكثر شيوعًا في السوق ، ونرى حلول تتبع تحويل التجارة الإلكترونية التي تقدمها ، ومدى احترامها للخصوصية.

على النحو الأمثل

تم إنشاء طريقتين مختلفتين على النحو الأمثل للسماح بتتبع التحويل عبر البيئات.

الخيار 1: تمكين واستخدام BYOID

يمكن القيام بذلك عن طريق تمكين ميزة "إحضار معرف الزائر الخاص بك" على Optimizely. تتيح لك هذه الميزة تحديد معرف الزائر الخاص بك ، إما كملف تعريف ارتباط أو مفتاح تخزين محلي أو معلمة استعلام عنوان URL أو متغير جافا سكريبت. يتمتع بالعديد من المزايا بخلاف تخفيف ITP 2.x ، بما في ذلك منحك التحكم في إستراتيجية استمرارية معرفك ، والسماح بمعرف زائر موحد عبر منصات متعددة ، وتقليل حجم ملفات تعريف الارتباط.

هذا الخيار هو عملية يدوية مملة تحتاج إلى تحديدها لكل عميل أو مجال حيث تقوم بتشغيل الخبرات. تحتاج أيضًا إلى توخي الحذر من أن المعرفات الفريدة التي تقوم بإنشائها سيتم التقاطها بنجاح بواسطة Optimizely API.

الخيار 2: تعيين optimizelyEndUserId على CDN

لا يُنصح بهذه الطريقة عادةً لأن BYOID هو نهج أكثر اكتمالاً. ولكن هناك طريقة أخرى لتكوين إنشاء ملفات تعريف الارتباط وهي من خلال CDN. يعد هذا خيارًا قابلاً للتطبيق للتنفيذ المستند إلى واجهة المستخدم والمُدار بواجهة المستخدم لإنشاء ملفات تعريف الارتباط من جانب الخادم في كثير من الحالات. يوفر Optimizely حاليًا وثائق لإنشاء ملفات تعريف الارتباط من جانب الخادم من خلال تكوين Akamai.

إذا كنت تتبع هذه العملية ، فبالإضافة إلى تغييرات إعدادات CDN المذكورة أعلاه ، يجب عليك أيضًا تعطيل تمديد العمر التلقائي لملف تعريف ارتباط معرف الزائر عن طريق تشغيل هذا في مشروع JS:

 نافذة ["على النحو الأمثل"]. ادفع ({
 "type": "extensionCookieLifetime" ،
 "isEnabled": خطأ
}) ؛

تتمتع هذه الإستراتيجية أيضًا بوظائف محدودة عند تمكين التتبع عبر النطاقات ، خاصةً عندما تتبع المجالات المختلفة إستراتيجيات مختلفة لاستمرار معرف الزائر.

فولكس فاجن

يدعم VWO التتبع عبر النطاقات بمساعدة ملفات تعريف الارتباط التابعة لجهات خارجية.

إذا قمت بتمكين خيار ملفات تعريف ارتباط الطرف الثالث في اختبارك ، بالإضافة إلى تخزين بيانات الزائر (يظهر التباين وأهداف التحويل) في ملفات تعريف الارتباط الخاصة بنطاقك ، فسوف ترسل VWO تلك البيانات إلى الخوادم أيضًا. بمجرد إرسال البيانات ، تقوم خوادم VWO بتعيين ملفات تعريف الارتباط للمجال dev.visualwebsiteoptimizer.com. إذا كان اختبارك يتضمن مجالًا آخر ، في المرة التالية التي تطلب فيها صفحتك بيانات اختبار ، ترسل خوادم VWO بيانات الزائر أيضًا. بطريقة ما ، تعمل الخوادم كوكيل بين نطاقاتك المختلفة المتعددة ، وبالتالي يمكن تتبع التحويلات.

ومع ذلك ، فإن متصفحي Firefox و Safari يحظران ملفات تعريف ارتباط الطرف الثالث افتراضيًا. نتيجة لذلك ، لا يمكن لـ VWO الوصول إلى ملفات تعريف ارتباط الطرف الثالث ، وبالتالي منع التتبع عبر المجال من العمل في متصفحات Safari و Firefox.

جوجل الأمثل

لتنفيذ التتبع عبر النطاقات من Google Optimize بنجاح ، يجب أن تعرف HTML و Javascript أو الحصول على مطور ويب مخصص لذلك.

لإعداده ، أنشئ موقعًا واحدًا في حسابك في Google Analytics.

بعد ذلك ، سيتعين عليك استخدام نفس معرف تتبع Google Analytics على كلا الموقعين اللذين تريد ربطهما.

1. يقوم المجال المصدر بتزيين عناوين URL التي تشير إلى المجال الوجهة بحيث تحتوي على قيم ملفات تعريف ارتباط قياس الطرف الأول للمجال المصدر.
2. يتحقق المجال الوجهة من وجود ملفات تعريف ارتباط القياس المرتبطة.

يتم تحديد معلمة linker في معامِلات استعلام URL بالمفتاح _gl ، كما في المثال أدناه:

https://www.example.com/؟ _gl = 1 ~ abcde5 ~

كاميليون

يقوم الحل الخاص بهم بإنشاء مقتطف من جانب الخادم يتزامن تلقائيًا مع التخزين المحلي. لذلك يوصون بتثبيت مقتطف من جانب الخادم يقوم تلقائيًا بمزامنة ملف تعريف الارتباط kameleoonVisitorCode الخاص بهم بين الواجهة الأمامية والخلفية. يحتوي هذا على معرّف رمز الزائر المهم جدًا.

لا تفرض ITP أي قيود على ملفات تعريف الارتباط من جانب الخادم ، لذلك سيكون لملف تعريف الارتباط هذا تاريخ انتهاء صلاحية محدد بشكل كافٍ في المستقبل.

سيقوم المقتطف بإنشاء جانب خادم ملف تعريف الارتباط KameleoonVisitorCode عندما لا يتم العثور على ملف تعريف ارتباط Kameleoon (على سبيل المثال ، لم يتم إنشاؤه من الجانب الأمامي) أو استرداد القيمة الحالية وإعادة إنشاء جانب خادم ملف تعريف الارتباط لتجنب مشكلات ITP. تعني المزامنة أنه لن تتم إزالة المعرفات بعد سبعة أيام فقط ، ولكن لن يكون هناك أي تأثير على الأداء أو تجربة المستخدم لأننا سنخزن ملف تعريف ارتباط واحد فقط.

ومع ذلك ، نظرًا لأن Kameleoon يخزن بيانات أخرى في Local Storage ، وهي البيانات اللازمة لبدء تجارب في الوقت الفعلي بدون مكالمات خادم إضافية ، فقد طبقوا أيضًا آلية مزامنة التخزين المحلي.

في Safari ، بمجرد حصول Kameleoon على رمز الزائر الخاص به عن طريق قراءة ملف تعريف الارتباط kameleoonVisitorCode ، سيتحقق مما إذا كان التخزين المحلي الحالي فارغًا. إذا كانت هذه هي الحالة ، مما يعني على الأرجح أن الزيارة الأخيرة كانت منذ أكثر من سبعة أيام ، فسيقومون بإجراء مكالمة مزامنة الخادم (SSC) لجلب جميع البيانات التي كانت موجودة في التخزين المحلي من خوادمهم الخلفية. بمجرد انتهاء هذا الاستدعاء ، ستتم استعادة البيانات في الحالة التي كانت عليها بالضبط إذا لم يقم ITP بمسحها. يمكن بعد ذلك استئناف العمليات العادية.

كيف يمكن لتحويل الخبرات إدارة التتبع عبر البيئات؟

يحترم برنامج Convert Experiences جميع قواعد الخصوصية ، ولا يسمح افتراضيًا بالتتبع عبر النطاقات وعبر الأجهزة والمستعرضات .

ومع ذلك ، إذا أراد المستخدمون ذلك ، يمكنهم تمكين التتبع عبر المجالات في إعدادات المشروع الخاصة بهم ويمكنهم مطالبة فريق دعم التحويل بالحلول المخصصة في التتبع عبر الأجهزة. التتبع عبر المستعرضات غير مدعوم.

الآن ، دعنا نرى المزيد من التفاصيل حول كل نوع من أنواع التتبع وكيفية إعداده في التطبيق.

التتبع عبر المجالات في تحويل الخبرات

يصف هذا القسم كيفية تعامل "تحويل الخبرات" مع التتبع عبر النطاقات ؛ على سبيل المثال ، إذا كان موقع الويب الخاص بك يمتد على أسماء نطاقات متعددة. هذا هو الحال غالبًا إذا كنت تستخدم عربة تسوق تابعة لجهة خارجية.

يتم إيقاف تشغيل التتبع عبر النطاقات افتراضيًا لجميع المشاريع في "تحويل التجارب" ، بسبب القانون العام لحماية البيانات (GDPR). ومع ذلك ، يمكنك إلغاء تحديد الإعداد "عدم السماح بالربط عبر النطاقات" لجعل التتبع ممكنًا:

في تطبيق Convert Experiences ، يتم تنظيم التجارب داخل المشاريع. المشروع عبارة عن كيان يمكن أن يحتوي على أي عدد من الخبرات والذي يتضمن المجالات (مواقع الويب النشطة):

تشارك جميع مواقع الويب الموجودة في برنامج Convert Project ملفات تعريف الارتباط ، مما يجعل التتبع عبر النطاقات ممكنًا ما لم تقم بتمكين إعداد المشروع "عدم السماح بالربط عبر النطاقات" أعلاه.

تتم طريقة مشاركة ملفات تعريف الارتباط بين المجالات عن طريق تمرير ملفات تعريف الارتباط تلقائيًا بين المجالات التي تنتمي إلى نفس المشروع عندما ينقر الزائر على الروابط أو يرسل النماذج. يتم تمرير ملفات تعريف الارتباط هذه إلى المجالات الأخرى الخاصة بك من خلال متغيرات GET.

يتم إضافة متغيرين إلى سلسلة الاستعلام لتمرير ملفات تعريف الارتباط:

• _conv_v
• _conv_s

من الممكن أيضًا تمرير ملفات تعريف الارتباط يدويًا إلى الروابط أو النماذج المحددة. كل ما عليك فعله هو تمرير المتغيرين _conv_v و _conv_s في عنوان URL للرابط أو الإجراء الخاص بالنموذج.

 <a href = "http://www.myothersite.com/page.html" _conv_v ")) + '& _ conv_s =' + escape (convert.getCookie (" _conv_s "))؛ return false؛" >

الآن ، دعنا نطلعك على حالة استخدام التتبع عبر النطاقات في تحويل التجارب.

لنفترض أنني بدأت رحلتي على صفحة حدث أحتاج فيها إلى الاشتراك:

https: // domainA .com / reports / WCI / cpc-bndl

بمجرد أن أضطر إلى الدفع ، يعيد النطاق A توجيهي إلى صفحة عربة الدفع التي تقع ضمن النطاق B ويضيف ملفات تعريف الارتباط للتحويل الضرورية للتتبع عبر النطاقات كمعلمات استعلام عنوان URL ، مثل:

 https://domainB.com/EWCIAH80/wci-cpc-bndl/؟_conv_v=vi٪3A1*sc٪3A1*cs٪3A1635157350*fs٪3A1635157350*pv٪3A2*exp٪3A٪7B100323139.٪7Bv.1003114910- g.٪ 7B10037703.1-10037704.1٪ 7D٪ 7D٪ 7D & _conv_s = si٪ 3A1 * sh٪ 3A1635157349857-0.9940523874349994 * pv٪ 3A2

بمجرد أن أنتهي من سداد الدفعة ، أذهب إلى صفحة شكرًا للمجال أ:

 https://domainA.com/thanks/wci-cpc-bndl-thanks؟ -g.٪ 7B10037703.1-10037704.1٪ 7D٪ 7D٪ 7D & _conv_s = si٪ 3A1٪ 2Ash٪ 3A1635157349857-0.9940523874349994٪ 2Apv٪ 3A2

حيث أعتبر زائرًا حاليًا ، لذلك يتم تسجيل تحويل الإيرادات عبر كلا النطاقين.

التتبع عبر الأجهزة في تحويل الخبرات

لا يدعم برنامج Convert Experiences التتبع عبر الأجهزة افتراضيًا. تم تصميم الطريقة أدناه فقط للحلول المخصصة وبناءً على طلب خطط القائد . لم يعد نشطًا ، لكننا نقدمه هنا للأغراض التعليمية.

من أجل تتبع الزوار على أجهزة مختلفة وتقديم تجربة مستخدم متسقة ، بغض النظر عن الجهاز الذي يستخدمونه ، يجب "تحديد" المستخدم من خلال نوع من المعرف الفريد الذي لا ينبغي أن يحتوي على أي بيانات تعريف شخصية (PII) .

أنشأ التحويل وظيفة API يمكن للعملاء من خلالها تقديم هذا المعرف الفريد الذي يحدد الزائر عبر الأجهزة. يجب "تقديم" المعرف الفريد في الصفحة ، قبل مقتطف تتبع التحويل الرئيسي.

تبدو هكذا:

 window._conv_q = window._conv_q || {} ؛
_conv_q.push ([“تحديد”، “unique_hashed_id_here”])؛

عندما يتم توفير المعرف الفريد ، فإن التحويل سيؤخر عرض التجربة حتى يستفسر من الخادم عن البيانات (التجارب التي تمت مشاهدتها ، والأهداف التي تم إطلاقها ، وما إلى ذلك) ويستعيد النتائج. عندما يتم إرجاع النتائج ، يتم حفظها في ملف تعريف ارتباط طويل المدى يحل محل الحاوية النهائية التي كان لدى المستخدم قبل "تحديدها". نتوقع أن يتم ذلك فقط إذا لم تكن البيانات متاحة بالفعل في ملف تعريف الارتباط طويل المدى ، لتجنب التأخير في تقديم التجربة في كل مشاهدة صفحة.

يجب تصغير الاستجابات وضغطها لتجنب فترات انتقال الشبكات الإضافية. يتكون الحل النهائي من طلبين مقدمين من الصفحة:

• الطلب الأول مسؤول عن تحميل ملف js الرئيسي (بيانات التحميل) - يتم تخزينه مؤقتًا على مستوى CDN ويحتوي على جميع التجارب المتاحة وتبعيات مكتبة jquery والأهداف ووظائف الاستخدام الأخرى والتتبع ، ولكنه لا يحتوي على مجموعة من المستخدمين. يتم تقديم هذا الملف مصغرًا ومضغوطًا (gzip).
• الاستدعاء الثاني هو بضع بايت في الحجم. يحاول الحصول على الحاويات المعينة مسبقًا لهذا المستخدم المعين. يقوم بتحميل معرفات التجارب ومعرفات الأهداف التي تم تعيين المستخدم إليها مسبقًا من خلال الوصول إلى قاعدة بيانات NoSQL ذات القيمة الرئيسية (المخزنة مؤقتًا داخل نظام التخزين المؤقت للذاكرة). إذا كانت هناك حاجة إلى مزيد من التحسينات في الأداء ، فسيتم تحسين التحويل باستخدام CDN أمامه (في هذه الحالة ، سيتم تخزين كل طلب مؤقتًا لكل مستخدم). يتم تقديم هذه الاستجابة أيضًا بشكل مصغر ومضغوط (gzip).

عندما يتم توفير المعرف الفريد لزائر جديد فريد لموقع الويب ، يتم جمع الخبرات بهذه الطريقة:

1. لمستخدم جديد - لا توجد ملفات تعريف ارتباط طويلة المدى مخزنة ؛ إذا تم توفير المعرف الفريد ، فسيتم تأخير التجارب حتى ترجع المكالمة الثانية. هذه المكالمة سوف:
   1. إما إرجاع التجارب / الأشكال المرتبطة بالمعرف الفريد ، وفي هذه الحالة ستعرض التحويل نفس زوج التجربة / التباين للمستخدم (يتصرف بنفس الطريقة التي يتصرف بها الزائر الذي يعود إلى صفحة التجربة التي تمت مشاهدتها من قبل)
   2. أو لن يقوم بإرجاع البيانات إذا كان هذا المعرف الفريد لا يحتوي على أي شيء متصل به ، وفي هذه الحالة ، سيقوم التحويل بإجراء التوزيع العشوائي كالمعتاد ؛ نتيجة لذلك ، عند تعيين حاوية جديدة ، سيكون هناك استدعاء إضافي غير متزامن للواجهة الخلفية لحفظ الحاوية الجديدة التي حدثت للتو.

عندما يتم توفير المعرف الفريد لزائر موقع ويب حالي ، فإن تجميع التجارب يتم على النحو التالي:

2. بالنسبة لمستخدم حالي (بمعرف) - لدينا ملف تعريف الارتباط طويل المدى الموجود في متصفحهم والذي تم تعيينه بواسطة التحويل. إذا تم توفير معرّف فريد ، فقد تكون لدينا إحدى هاتين الحالتين:
   1. لا توجد جلسة تصفح بدأت (يتم تحديد جلسة جديدة من خلال ملف تعريف ارتباط للجلسة تنتهي صلاحيته بعد 20 دقيقة من عدم النشاط) أو يختلف معرف الزائر المخزن في ملف تعريف الارتباط طويل المدى عن معرف الزائر المقدم من خلال المعرف الفريد ؛ in this case, the same thing as in the previous example will happen: when bucketing is returned from the server, it will overwrite current bucketing stored on the long-term cookie; If the server returns no data, the long-term cookie will prevail. This overwriting can become problematic when, for the same user, part of the session has a unique identifier and part of it does not.
   2. A current browsing session started and the visitor ID stored on the long-term cookie is the same as the unique identifier provided. In this case, the process is the same as usual: it's a user for which eventually the bucketing was restored at the first pageview of the user session, therefore, no additional requests are required (no second call to retrieve the data since it's already in the long-term cookie, nor a third call to save any bucketing that would've had happened otherwise).

Cross-Browser Tracking in Convert Experiences

Convert Experiences does NOT support cross-browser tracking.

How to Test if Cross-Domain Tracking Works?

Here are some tell-tale signs you can look for in your Convert reports that can indicate that cross-domain tracking isn't working right:

• There is less traffic than you would expect,
• Your conversions are not triggered/captured,
• Traffic on one domain has various campaigns being attributed, while another domain includes less traffic.

Basically, if your Convert report is accounting for less traffic or fewer conversions than you'd expect, this could mean Convert is losing track of the attribution when your users switch domains. That might be an indication that cross-domain tracking isn't working properly.

Things to Consider When You Enable Cross-Domain Tracking

• You do not need to enable cross-domain tracking for subdomains in your account.
• Cross-domain tracking must be enabled when the original and variation URLs in a Split URL test are on different domains.
• For enhanced privacy, the Firefox and Safari browsers block cross-domain tracking by default. As a result, Convert cannot access the third-party cookies, thereby prohibiting cross-domain tracking from working in Safari and Firefox browsers. However, the default browser settings can be disabled:
  • In the Safari browser, go to Preferences > Privacy and disable the Prevent cross-site tracking setting.
  • In the Firefox browser, go to Preferences > Privacy & Security > Custom and disable the “Cookies and Tracking Content” setting.
• With the iOS 14 and macOS 11 upgrade, Apple introduced the Privacy Report feature in Safari. You can use this to examine a website's report to see which websites are tracking you and display the trackers that Safari has blocked. The report shows both cross-site tracking trackers and those detected by Apple's intelligent tracking prevention.
  Please note that this does not have any impact on your Convert experiences as our app only works with first-party cookies. Convert tracking would only be affected when you use the cross-domain tracking feature on Safari since the browser does not allow working with third-party cookies by default.

There are a lot of things to think about when it comes to tracking ecommerce conversions in A/B testing. It's not as simple as just looking at your web analytics reports or cookies, because customers may be seeing your digital marketing campaigns in one environment before converting on another. Today's consumers use an increasing number of touchpoints throughout their journey, which can get tracking info difficult for marketers.

Fortunately, A/B testing tools like Convert Experiences give users the ability to see how individuals interact with their online business, all while making sure that user privacy rights are upheld. Click the banner below to take a free trial and see for yourself how this works.