ITP 2.2 من Apple: انتهاء صلاحية تتبع ملفات تعريف الارتباط ليوم واحد عبر Link Decoration

أنشأت Apple ITP باسم الخصوصية.

بشكل أساسي ، جعل ITP الأصلي من الصعب استخدام ملفات تعريف ارتباط الطرف الثالث لتتبع مستخدمي Safari على iOS و MacOS وهو يتماشى مع جهود Firefox ETP في الخصوصية. أضافت نافذة مدتها 24 ساعة إلى ملفات تعريف الارتباط في المجالات التي حددتها حتى يمكن تتبعها عبر المجالات ، وبعد ذلك تم حظر الوصول إلى ملفات تعريف الارتباط التابعة لجهات خارجية. تسبب هذا في مشاكل للعديد من موفري التتبع نظرًا لأن قدرًا كبيرًا من التتبع يتم باستخدام ملفات تعريف الارتباط التابعة لجهات خارجية.

كان الحل الشائع للمسوقين هو التبديل إلى ملفات تعريف ارتباط الطرف الأول. ومع ذلك ، في إصدارات ITP اللاحقة (2.0 و 2.1 و 2.2) ، بدأت Apple في الحد من استخدام ملفات تعريف ارتباط الطرف الأول أيضًا. في وقت سابق من هذا العام ، في ITP 2.1 ، قامت Apple بتحديث ITP لحساب الحل البديل الذي توصلت إليه الشركات حيث سيكون لديهم موقع يقوم بإسقاط ملف تعريف ارتباط الطرف الأول الذي يحاكي وظيفة ملف تعريف ارتباط الطرف الثالث. باستخدام ITP 2.1 ، يحذف Safari ملفات تعريف ارتباط الطرف الأول هذه بعد سبعة أيام من تثبيتها على المستعرض.

أكبر تغيير لـ ITP 2.2 من 2.1 و 2.0 يحد من مدة بعض ملفات تعريف ارتباط الطرف الأول التي تم تعيينها على JavaScript ليوم واحد - أقل من الأيام السبعة التي نفذها ITP 2.1.

لكي يتم وضع حد أقصى لملف تعريف الارتباط في يوم واحد بواسطة ITP 2.2 ، يجب استيفاء ثلاثة شروط:

1. يتم تعيين ملف تعريف الارتباط عبر JavaScript (أو بكلماتهم ، "تعيين من خلال document.cookie"). تم تطبيق هذا الشرط أيضًا مع ITP 2.1 (انظر أيضًا مدونتنا على ITP 2.1 لاختبار A / B).
2. تم تصنيف الموقع الذي أرسل المستخدم إلى الصفحة المقصودة بواسطة ITP على أنه "يتمتع بإمكانيات تتبع عبر المواقع" (من المؤكد أن شبكات الإعلانات الرئيسية وجوجل وفيسبوك مصنفة بهذه الطريقة)
3. يستخدم الرابط زخرفة الارتباط (يستخدم معلمات سلسلة الاستعلام و / أو معرف الجزء)

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

الشرط 1: ملفات تعريف الارتباط الدائمة المنشأة عبر document.cookie

من الآن فصاعدًا ، سيتم تعيين جميع ملفات تعريف الارتباط الدائمة التي تم إنشاؤها عبر ملف تعريف الارتباط الخاص بجافا سكريبت (على عكس ملفات تعريف الارتباط التي تم تعيينها بواسطة HTTP) بحيث تنتهي صلاحيتها خلال 24 ساعة إذا تم تحديد نطاق الإحالة على أنه يحتوي على إمكانات تتبع عبر المواقع ويحتوي عنوان URL على سلسلة استعلام أو معرّف الجزء. ستنتهي صلاحية جميع ملفات تعريف ارتباط الطرف الأول التي تم إنشاؤها بواسطة document.cookie والتي لم يتم إنشاؤها عبر سلسلة استعلام أو معرّف الجزء في غضون 7 أيام (كما هو مذكور في ITP 2.1).

يتم إنشاء ملفات تعريف الارتباط المحولة عبر document.cookie الخاصة بجافا سكريبت ، لذا يتم تطبيق الشرط الأول بموجب ITP2.2 . (كما تم تطبيقه أيضًا بموجب ITP 2.1).

الشرط 2: إحالة المجال مع إمكانيات التتبع عبر المواقع

يتم تصنيف المجالات ديناميكيًا ضمن ITP بواسطة خوارزمية التعلم الآلي:

1. كشف تعقب الارتداد للطرف الأول. يكتشف متى يتم استخدام المجال لتتبع إعادة التوجيه فقط. سيتم تطبيق هذا بشكل متكرر على جميع المجالات في سلسلة إعادة التوجيه.
2. المورد الفرعي تحت عدد المجالات الفريدة. يتعلق بعدد المسارات المتاحة ضمن المجال. تمتلك منصات التتبع حاليًا عددًا صغيرًا جدًا من هؤلاء.
3. الإطارات الفرعية تحت عدد المجالات الفريدة. يتعلق بعدد إطارات الصفحات المتاحة ضمن المجالات.
4. عدد المجالات الفريدة المعاد توجيهها إلى.
5. لا يحتوي النظام على قائمة بيضاء أو سوداء. بدلاً من ذلك ، سيُنشئ كل جهاز قائمة منع التتبع الخاصة به بناءً على استخدام الويب.

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

نظرًا لعدم وجود قائمة مركزية بالمجالات المصنفة لإمكانيات التتبع عبر المواقع ، سيحتاج مالكو المواقع إلى تقييم روابطهم وتقييم أي مكتبات JavaScript لجهات خارجية قد تستخدم زخرفة الارتباط. وهذا يشمل بائعي تكنولوجيا الإعلانات وشركات القياس والمسوقين المنتسبين وأنواع معينة من المؤثرين. يتأثر Facebook و Google بالتأكيد بـ ITP 2.2.

دعنا نوضح الأمر بمثال: تخيل أن لديك موقعًا www.example.com ، حيث تم تثبيت شفرة تحويل التتبع. إذا كان موقعك يتلقى زيارات من Google و Facebook (وهي المجالات المرجعية في هذه الحالة ، على سبيل المثال ، يهبط الزائر بعنوان URL هذا على موقعك: https://www.example.com؟utm_source=google) ، يتم تعيين جميع ملفات تعريف ارتباط الطرف الأول سيتم تقييد مدة www.example.com لمدة 24 ساعة ، نظرًا لأن حركة المرور هذه تأتي من مجال إحالة يُعتبر يمتلك إمكانات تتبع عبر المواقع وتوجد زخرفة ارتباط (انظر أدناه). وبالتالي ، ستكون مدة تحويل ملفات تعريف الارتباط 24 ساعة. ماذا يعني ذلك؟ إذا أجريت تجربة لمدة 7 أيام ، وزار أحد المستخدمين موقعك في اليوم الأول ثم في اليوم الثالث (بعد فجوة مدتها يومين) ، فلن يتمكن برنامج التحويل من التعرف على هذا الشخص كزائر عائد (لأن برنامج Convert's سيتم حذف ملف تعريف الارتباط الذي تم إنشاؤه بواسطة المتصفح بعد القيود الجديدة!). وسيتم التعامل مع هذا الزائر على أنه زائر جديد.

ومن ثم فإن هذا الشرط الثاني لا يتعلق بالتحويل نفسه ، بل يتعلق بالمجالات المرجعية.

الشرط 3: ربط الديكور

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

هناك طريقتان رئيسيتان لتزيين الرابط.

الطريقة الأساسية هي إرفاق المعلومات الإضافية بشكل ثابت بعنوان URL عند إنشاء ارتباط. فيما يلي مثال على ارتباط مزين:

https://www.example.com؟utm_source=google&utm_medium=cpc&utm_campaign=2019_promotion

المعلومات بعد؟ يُعرف باسم استعلام سلسلة ، والذي يتكون من معلمات (على سبيل المثال ، متوسط ​​=). شكل آخر من أشكال زخرفة الارتباط يستخدم معرفات الأجزاء ، والتي يتم تقديمها بواسطة علامة التجزئة (#).

الطريقة الأخرى الأكثر تعقيدًا لتزيين ارتباط هي تشغيل بعض كود Javascript الذي يتم تشغيله عندما ينقر شخص ما على ارتباط ويضيف معلومات إلى ارتباط ديناميكيًا. ستفعل الشركات ذلك عندما تريد تمرير معلومات خاصة بالنقرة الفردية التي قادت شخصًا ما إلى موقع الوجهة. على سبيل المثال ، قد يقوم المعلن بذلك لتتبع حملة إعلانية على الشبكة الإعلانية يتم تشغيلها عبر مواقع متعددة للناشرين وروابط إلى موقع المعلن. بدلاً من تخصيص الرابط يدويًا لكل ناشر يحمل إعلانه ، يمكن للمعلن إضافة الرمز "؟ publisher = [اسم الناشر]" إلى عنوان URL في الوقت الذي ينقر فيه الشخص على الإعلان. بهذه الطريقة يمكن للمعلن تحديد الناشر المسؤول عن إرسال زائر الموقع.

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

إليك الحل البديل للتحويل

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

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

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

قلق بشأن ITP 2.2؟ نحن نحافظ على تتبعك على المسار الصحيح

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

قد لا تظل العديد من الحلول الموجودة حاليًا قابلة للتطبيق على المدى الطويل إذا لم تتغير مع تغيير متطلبات الخصوصية وتتبع التحديثات.

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