إدارة حالة مستخدم غير مصادق عليه باستخدام AMP

فهرس المحتويات

• معلومات عامة
• دليل التنفيذ
• قبل البدء
• المهمة 1: بالنسبة للصفحات التي لا تدعم AMP الموجودة في مصدر الناشر، عليك بإعداد معرّف وإرسال رسائل فحص التحليلات
• المهمة 2: بالنسبة لصفحات AMP، إعداد معرّف وإرسال رسائل فحص التحليلات من خلال تضمين بديل لمعرّف العميل في رسائل فحص تحليلات AMP
• المهمة 3: معالجة رسائل فحص التحليلات من الصفحات الموجودة في مصدر الناشر
• المهمة 4: عرض معالجة رسائل اختبار التحليلات من ذاكرة AMP للتخزين المؤقت أو عارض AMP لسياقات وتخطيطات المعرّفات (إذا لزم الأمر)
• المهمة 5: استخدام معرّف العميل في الربط وتقديم النموذج
• الممارسات الموُصى بها بشدة

حالة المستخدم هي مفهوم مهم على شبكة الإنترنت اليوم. ضع في اعتبارك حالات الاستخدام التالية التي يتم تمكينها من خلال إدارة حالة المستخدم:

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

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

معلومات عامة

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

عرض السياقات لصفحات AMP

يمكنك التفكير في AMP كتنسيق محتوى محمول يتيح تحميل المحتوى بسرعة في أي مكان. يمكن عرض مستندات AMP عبر ثلاثة سياقات جديرة بالملاحظة:

• مصدر الناشر
• ذاكرة AMP للتخزين المؤقت
• عارض AMP

دعونا نفحص كل من هذه المواقف عن كثب.

السياق #1: مصدر الناشر. يتم نشر صفحات AMP بحيث يتم استضافتها في الأصل من موقع الناشر ويمكن الوصول إليها عبره، على سبيل المثال، على https://example.com قد يجد المرء https://example.com/article.amp.html.

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

ملاحظة: نظرًا لنموذج النشر "المزدوج" الموضح للتو، فإن مصدر الناشر (في المثال أعلاه، https://example.com) هو سياق يمكن من خلاله الوصول إلى المحتوى الذي يدعم AMP والذي لا يدعمه. في الواقع، هذا هو السياق الوحيد الذي يمكن أن يحدث فيه ذلك لأن ذاكرات AMP للتخزين المؤقت وعوارض AMP، الموصوفة أدناه، تقدم فقط محتوى AMP صالحًا.

السياق #2: ذاكرة AMP للتخزين المؤقت. يمكن تخزين ملفات AMP مؤقتًا في السحابة بواسطة ذاكرة تخزين مؤقت لطرف ثالث لتقليل الوقت الذي يستغرقه المحتوى للوصول إلى جهاز المستخدم المحمول.

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

بشكل تقليدي، المحتوى الذي يتم تقديمه بهذه الطريقة يتوّلد من نطاق مختلف. على سبيل المثال، تستخدم ذاكرة التخزين المؤقت Google AMP https://cdn.ampproject.org لتقديم المحتوى، مثل https://example-com.cdn.ampproject.org/s/example.com/article.amp.html.

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

تمامًا مثل حالة ذاكرة AMP للتخزين المؤقت، توقع أن يكون نطاق عارض AMP مختلفًا أيضًا عن مصدر الناشر. على سبيل المثال، تتم استضافة عارض بحث Google على https://google.com ويقوم بتضمين إطار iframe الذي يطلب محتوى الناشر من ذاكرة التخزين المؤقت Google AMP.

السياقات المتعددة تعني إدارة حالات متعددة

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

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

في اليوم الأول، تكتشف المستخدمة صفحة AMP من شركة Example Inc. عبر بحث Google. يُحمِّل بحث Google صفحات AMP في عارض AMP. أثناء عرض الصفحة، تضيف المستخدمة أربعة عناصر إلى عربة التسوق الخاصة بها ولكنها لا تقوم بإتمام الدفع. بعد أسبوعين، في اليوم الخامس عشر، تتذكر المستخدمة العناصر الأربعة التي كانت تفكر في شرائها وتقرر الآن أن الوقت قد حان لشرائها. يصلون إلى الصفحة الرئيسية لشركة Example Inc. على https://example.com مباشرةً (وهي صفحة رئيسية لا تدعم AMP) ويكتشفون أن عناصرهم الأربعة لا تزال محفوظة في عربة التسوق.

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

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

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

دليل التنفيذ

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

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

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

الجزء #2: استخدام معرّف العميل في الربط وتقديم النموذج: في المهمة 5، ستتعلم الاستفادة من اجتياز الربط و/أو تقديم النموذج لتمرير معلومات معرّف عميل AMP عبر الحدود السياقية حيث ينتقل المستخدم من صفحة واحدة مباشرةً إلى أخرى.

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

قبل البدء

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

من أجل الوضوح في باقي هذا المستند، سنقوم باستدعاء سلاسل مختلفة من الأحرف والتي تكون معرّفات بأسماء أكثر قابلية للقراءة مسبوقة بعلامة الدولار ($):

n34ic982n2386n30 ⇒ $sample_id

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

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

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

المهمة 1: بالنسبة للصفحات التي لا تدعم AMP الموجودة في مصدر الناشر، عليك بإعداد معرّف وإرسال رسائل فحص التحليلات

لنبدأ بتهيئة التحليلات للصفحات التي لا تدعم AMP التي يتم عرضها من مصدر الناشر. يمكن تحقيق ذلك بعدة طرق، بما في ذلك استخدام حزمة تحليلات مثل Google Analytics أو Adobe Analytics أو عن طريق كتابة تنفيذ مخصص.

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

تُقدم بقية هذه المهمة إرشادات إذا كنت تبحث عن إعداد تحليلاتك الخاصة.

إعداد معرّف باستخدام ملفات تعريف الارتباط الخاصة بالطرف الأول

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

من أجل المثال الخاص بنا، لنفترض أنك قمت بتعيين ملف تعريف ارتباط يسمى uid ("معرّف المستخدم")، الذي سيتم إنشاؤه في أول زيارة للمستخدم. إذا لم تكن الزيارة الأولى للمستخدم، فقم بقراءة القيمة التي تم تعيينها مسبقًا في الزيارة الأولى.

هذا يعني أن هناك وضعان لحالة الصفحات التي لا تدعم AMP على مصدر الناشر:

الحالة #1: الزيارة الأولية. عند الوصول لأول مرة على الصفحة التي لا تدعم AMP، لن يكون هناك ملف تعريف ارتباط. إذا قمت بالتحقق من ملف تعريف الارتباط قبل تعيين أحدها، فسترى أنه لا يوجد قيم تم تعيينها في ملف تعريف الارتباط المقابل لـ uid:

> document.cookie
> ""
> 

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

> document.cookie
> "uid=$publisher_origin_identifier"
> 

الحالة #2: زيارة غير أولية. سيكون هناك مجموعة ملفات تعريف الارتباط. وبالتالي، إذا فتحت وحدة تحكم المطور على الصفحة، فسترى:

> document.cookie
> "uid=$publisher_origin_identifier"
> 

إرسال رسائل فحص التحليلات

بمجرد إعداد معرّف، يمكنك الآن دمجه في رسائل فحص اتصال التحليلات لبدء تتبع مشاهدات الصفحة.

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

https://analytics.example.com/ping?type=pageview&user_id=$publisher_origin_identifier

لاحظ أنه في المثال أعلاه، تتم الإشارة إلى مُعرّف المستخدم بواسطة معلمة استعلام محددة، user_id:

user_id=$publisher_origin_identifier

يجب تحديد استخدام "user_id" هنا من خلال ما يتوقع خادم التحليلات الخاص بك معالجته وليس مرتبطًا بشكل خاص بما تسميه ملف تعريف الارتباط الذي يخزن المعرّف محليًا.

المهمة 2: بالنسبة لصفحات AMP، إعداد معرّف وإرسال رسائل فحص التحليلات من خلال تضمين بديل لمعرّف العميل في رسائل فحص تحليلات AMP

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

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

في صفحات AMP، أنشئ رسالة فحص تحليلات AMP تحتوي على معرّف العميل:

لاحظ حقيقة أن المعلمة التي تم تمريرها إلى بديل معرّف العميل، ${clientId(uid)، تكون uid. كان هذا اختيارًا متعمدًا يطابق نفس اسم ملف تعريف الارتباط المستخدم في مصدر الناشر كما هو موضح في المهمة 1. لتحقيق التكامل الأكثر سلاسة، يجب عليك تطبيق نفس التقنية.

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

من المفيد أن تعلم مايلي: لماذا استخدمنا الاسم uid للمعلمة التي تم تمريرها إلى ميزة معرّف العميل؟ يتم استخدام المعلمة التي يستخدمها بديل clientId(...) لتحديد النطاق التي تُستخدم فيه. يمكنك بالفعل استخدام ميزة Client ID للعديد من حالات الاستخدام، ونتيجة لذلك، يمكنك إنشاء العديد من معرفات العملاء. تميّز المعلمة بين حالات الاستخدام هذه ولذا تستخدمها لتحديد حالة الاستخدام التي تريد معرّف العميل لها. على سبيل المثال، قد ترغب في إرسال معرّفات مختلفة إلى جهات ثالثة مثل أحد القائمين على الإعلان ويمكنك استخدام معلمة "النطاق" لتحقيق ذلك.

في مصدر الناشر، من الأسهل التفكير في "النطاق" كما لو أنك تدعوه ملف تعريف الارتباط. من خلال التوصية بقيمة uid لمعلمة معرّف العميل هنا في المهمة 2، فإننا نتماشى مع خيار استخدام ملف تعريف ارتباط يُدعى uid في المهمة 1.

المهمة 3: معالجة رسائل فحص التحليلات من الصفحات الموجودة في مصدر الناشر

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

وهذا موضح في الجدول أدناه:

المهمة 4: عرض معالجة رسائل اختبار التحليلات من ذاكرة AMP للتخزين المؤقت أو عارض AMP لسياقات وتخطيطات المعرّفات (إذا لزم الأمر)

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

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

مراجعة المشكلة

ضع في اعتبارك التدفق التالي:

1. يزور أحد المستخدمين صفحة AMP في سياق عرض عارض AMP، مثل https://google.com/amp/s/example.com/article.amp.html. نظرًا لأن عارض AMP لا يمتلك حق الوصول إلى ملف تعريف الارتباط uid في مصدر الناشر، يتم إنشاء قيمة عشوائية بقيمة $amp_client_id لتحديد هوية المستخدم.
2. ثم يزور المستخدم نفسه صفحة على مصدر الناشر https://example.com. كما هو موضح في المهمة 3، ثم يتم تعريف المستخدم بـ $publisher_origin_identifier0.

إليك نقطتين، حيث يقع كل من (1) و (2) في مصادر (أو سياقات) مختلفة. لهذا السبب، لا توجد حالة مشتركة ويختلف $amp_client_id عن $publisher_origin_identifier. إذن، ما هو التأثير؟ التأثير (1) هو جلسة مشاهدة صفحة واحدة تبدو وكأن مستخدم واحد قام بها، إما بالنسبة للتأثير (2) هو جلسة مشاهدة صفحة واحدة أخرى يبدو أنها واردة من مستخدم آخر.  بشكل مُبسط، على الرغم من استمرار تفاعل المستخدم مع محتوى https://example.com، فإننا نزيد عدد المستخدمين ويبدو أن المستخدم في التأثير (1) يرتد (حيث يقوم بزيارة واحدة للصفحة).

استراتيجية الحل

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

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

خطوات التنفيذ

على الخادم، تحقق من معرّف مصدر الناشر الحالي

اقرأ ملفات تعريف الارتباط المرسلة كجزء من طلب التحليلات. في مثالنا، هذا يعني التحقق من ملف تعريف الارتباط الخاص بـ uid من example.com.

• إذا تمت قراءة قيمة uid بنجاح، فاستخدمها لتسجيل بيانات التحليلات أو (معرّف سجل التحليلات). بسبب المهمة 1 ، نعلم أن قيمة هذا المعرّف هي $publisher_origin_identifier. مع إنشاء معرّف سجل التحليلات، يمكننا التخطي إلى قسم تخزين البيانات.
• إذا لم تتم قراءة قيمة uid بنجاح، فتابع الخطوات التالية التي تتضمن جدول التعيين.

جدول التعيين

سيربط جدول التعيين الخاص بنا قيم معرّف عميل AMP التي تظهر في رسائل فحص التحليلات بمعرفات مصدر الناشر على النحو التالي:

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

https://analytics.example.com/ping?type=pageview&user_id=$amp_client_id

نستخرج الجزء الغامق المقابل لمعرّف عميل AMP: $amp_client_id.

بعد ذلك، افحص جدول التعيين لمحاولة العثور على نفس القيمة في عمود "الاسم المستعار":

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

خلافًا لذلك، إذا لم يتم العثور على معرّف عميل AMP في التعيين، فسنحتاج إلى إنشاء تعيين:

1. إنشاء معرف أصل ناشر محتمل. دعنا نسمي هذا $prospective_identifier في الأمثلة التالية. يجب إنشاء هذه القيمة وفقًا لكيفية إعداد القيمة في مصدر الناشر، كما هو موضح في المهمة 1 أعلاه.
2. بعد ذلك، حاول تعيين معرف مصدر الناشر المحتمل كملف تعريف ارتباط على مصدر الناشر. سينجح هذا إذا كان من الممكن كتابة ملفات تعريف ارتباط الطرف الثالث، وإلا فسوف تفشل المحاولة.
3. بعد ذلك، احتفظ بزوج {prospective publisher origin identifier, AMP Client ID}.

يُفضي التعيين الذي أنشأناه إلى الشكل التالي:

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

تخزين البيانات

الآن بعد أن اكتشفت معرّف سجل التحليلات، يمكنك بالفعل تخزين معلومات حالة المستخدم (بيانات التحليلات في هذه الحالة) التي تم تحديدها بواسطة هذا المعرف:

{analytics record identifier, analytics data ...}

المهمة 5: استخدام معرّف العميل في الربط وتقديم النموذج

بشكل عام، عند عدم السماح بقراءة ملفات تعريف ارتباط الطرف الثالث وكتابتها، ستكون هناك مواقف يكون فيها من المستحيل إدارة حالة المستخدم بفعالية كاملة. في المهام من 1 إلى 4، تساعد الخطوات التي اتخذناها بطريقتين: (1) أنها توفر حلاً فعالاً تمامًا عندما يُسمح بقراءة ملفات تعريف ارتباط الطرف الثالث وكتابتها، و (2) قاموا بإعداد نظامنا للاستفادة من أي فرصة نهائية للتوفيق بين معرفات السياقات المتداخلة إذا كانت التسوية الفورية مستحيلة بسبب إعدادات ملفات تعريف الارتباط في المتصفح.

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

استخدام ميزات بديلة

المنهج الخاص بنا سيستفيد من فئتين من بدائل AMP المختلفة.

 لتحديث الروابط الخارجية لاستخدام بديل لمعرف العميل: حدد معلمة جديدًا للاستعلام، ref_id (“referrer ID”)، والذي سيظهر داخل عنوان URL ويشير إلى إنشاء معرّف السياق للمستخدم. عيِّن معلمة الاستعلام هذه بحيث تساوي قيمة بديل معرِّف عميل AMP:

<a
href="https://example.com/step2.html?ref_id=CLIENT_ID(uid)"
data-amp-replace="CLIENT_ID"

> </a>
> 

حل بديل لتمرير معرّف العميل إلى الروابط الخارجية: حدد معلمة البحث الجديدة ref_id كجزء من سمة بيانات data-amp-addparams وبالنسبة للاستعلامات التي تحتاج إلى توفير بديل للمعلمة، قم بتوفير هذه التفاصيل كجزء من data-amp-replace. باستخدام هذا المنهج، سيبدو عنوان URL نظيفًا وستتم إضافة المعلمات المحددة في data-amp-addparams ديناميكيًا

<a
href="https://example.com/step2.html"
data-amp-addparams="ref_id=CLIENT_ID(uid)"
data-amp-replace="CLIENT_ID"

> </a>
> 

لتمرير معلمات استعلام متعددة من خلال data-amp-addparams قم بفصل كل من & بهذا الشكل

<a
href="https://example.com/step2.html"
data-amp-addparams="ref_id=CLIENT_ID(uid)&pageid=p123"
data-amp-replace="CLIENT_ID"

> </a>
> 

لتحديث مدخلات النماذج لاستخدام بديل معرّف العميل: حدد اسمًا لحقل الإدخال، مثل orig_user_id. ثم حدد default-value لحقل النموذج لتكون قيمة بديل معرّف عميل AMP:

<input
  name="ref_id"
  type="hidden"
  value="CLIENT_ID(uid)"
  data-amp-replace="CLIENT_ID"
/>

من خلال اتباع هذه الخطوات، يكون معرف العميل متاحًا للخادم المستهدف و/أو كمعلمة عنوان URL على الصفحة التي يصل إليها المستخدم بعد النقر على الرابط أو إرسال النموذج (سياق الوجهة). سيكون الاسم (أو "المفتاح") هو ref_id لأن هذه هي الطريقة التي حددناه بها في عمليات التنفيذ المذكورة أعلاه وسيكون له قيمة مرتبطة تساوي معرّف العميل. على سبيل المثال، باتباع الرابط (علامة <a>) المحددة أعلاه، سيتصفح المستخدم عنوان URL هذا:

https://example.com/step2.html?ref_id=$amp_client_id

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

استخراج معلمات استعلام عنوان URL

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

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

إذا كانت المعلومات متاحة عبر عنوان URL وترغب في معالجتها، فهناك طريقتان يمكنك استخدامهما:

• المعالجة أثناء إعادة التوجيه (معالجة من جانب الخادم)
• المعالجة على صفحة الوصول (المعالجة من جانب العميل)

المعالجة أثناء إعادة التوجيه (معالجة من جانب الخادم)

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

المعالجة على صفحة الوصول (المعالجة من جانب العميل)

للمعالجة على صفحة الوصول، سيختلف الأسلوب اعتمادًا على ما إذا كانت هذه الصفحة داعمة لـ AMP أو غير ذلك.

تحديثات صفحة AMP: استخدم ميزة استبدال "معلمة الاستفسار" في تهيئة amp-analytics للحصول على قيمة المعرف ref_id داخل عنوان URL. تأخذ ميزة "معلمة الاستفسار" معلمة تشير إلى "مفتاح" زوج القيمة الرئيسية المطلوب في عنوان URL وتعيد القيمة المقابلة. استخدم ميزة معرّف العميل كما فعلنا للحصول على المعرّف لسياق صفحة AMP.

https://analytics.example.com/ping?type=pageview&orig_user_id=${queryParam(ref_id)}&user_id=${clientId(uid)}

عندما يتم نقل هذا عبر الشبكة، سيتم استبدال القيم الفعلية:

https://analytics.example.com/ping?type=pageview&orig_user_id=$referrer_page_identifier&user_id=$current_page_identifier

متابعة من خلال الأمثلة أعلاه، لدينا:

$referrer_page_identifier is $amp_client_id
$current_page_identifier is $publisher_origin_id

لذلك فإن رسائل الفحص هي في الواقع:

https://analytics.example.com/ping?type=pageview&orig_user_id=$amp_client_id&user_id=$publisher_origin_id

نوصي بالتحقق من صحة قيم معلمات الاستعلام باستخدام الخطوات الموضحة في قسم التحقق من صحة المعلمة أدناه.

تحديثات لصفحة ليست AMP: بالمثل، على صفحة ليست AMP يتم عرضها من أصل الناشر، استخرج وأرسل قيمة ref_id المضمنة في عنوان URL. تحقق من صحة القيمة باتباع الخطوات الموضحة في قسم التحقق من صحة المعلمة أدناه. بعد ذلك، أنشئ اختبارات فحص البيانات التحليلية التي ستتضمن كلاً من orig_user_id مشتق من ref_id{/ code4} و<code data-md-type="codespan">user_id استنادًا إلى قيمة معرف ملف تعريف ارتباط الطرف الأول.

هام:

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

قبل إزالة المعلمات، تأكد من أن التعليمات البرمجية الأخرى التي يجب تشغيلها لقراءتها إما:

• تعمل قبل حدوث الإزالة؛ أو
• يمكنها الوصول إلى مكان حيث قامت التعليمة البرمجية التي قرأت وأزالت المعلمات بتخزين البيانات

لإجراء ذلك على صفحتك التي ليست بتنسيق AMP، ضمِّن JavaScript التالية، والتي ستزيل جميع معلمات الاستعلام من عنوان URL:

var href = location.href.replace(/\?[^#]+/, '');
history.replaceState(null, null, href);

قم بتعديل هذا حسب الحاجة لإزالة عدد أقل من معلمات الاستعلام.

معالجة معرّفات متعددة في رسالة فحص التحليلات

على عكس المهمة 4 حيث قمنا بتكوين رسالة فحص التحليلات لاحتواء قيمة معرّف واحدة فقط، مع الخطوات التي اتخذناها حتى الآن في المهمة 5، أصبح لدينا الآن اثنان - orig_user_id وuser_id. سنغطي بعد ذلك كيفية معالجة هذين المعرّفين اللذين يشكّلان جزءًا من رسالة فحص التحليلات الواردة.

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

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

الحالة رقم 1: ترتيب المعرّف عند إرسال رسالة فحص التحليلات من الصفحة الموجودة في أصل الناشر

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

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

الحالة رقم 2: ترتيب المعرّف عندما يتم إرسال رسالة فحص التحليلات من صفحة AMP ليست موجودة في أصل الناشر

عندما تقوم بالبحث في جدول التعيينات، قم بتدوين الموقف الذي ينطبق وابحث عن القيم داخل أعمدة جدول التعيينات حيث تتوقع ظهورها. على سبيل المثال، إذا تم إرسال اختبار الاتصال التحليلي من صفحة على أصل الناشر (الحالة رقم 1)، فتحقق من القيم التي تم ترميزها بواسطة user_id في عمود جدول التعيينات "معرف المستخدم في أصل الناشر" وتحقق من القيم التي تم إدخالها بواسطة orig_user_id في العمود "معرّف المستخدم في صفحة AMP التي ليست موجودة في أصل الناشر ("الاسم المستعار")".

إذا لم تتمكن من تحديد موقع قيمة المعرف المستخدمة في جدول التعيينات، فقم بإنشاء تعيين جديد:

• إذا كان طلب التحليلات يأتي من صفحة موجودة في أصل الناشر، فعليك اختيار القيمة المقابلة لـ uid لتكون معرّف سجل التحليلات؛ اختر قيمة orig_uid لتكون "الاسم المستعار".
• إذا كان طلب التحليلات لا يأتي من صفحة موجودة في أصل الناشر، فيجب عليك اختيار القيمة المقابلة لـ uid لتكون قيمة "الاسم المستعار" في جدول التعيينات. بعد ذلك، تابع التعليمات المتبقية في المهمة 4 لإنشاء معرف أصل ناشر محتمل وحاول تعيين هذه القيمة كملف تعريف ارتباط على الأصل.

التحقق من صحة المعلمة

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

على سبيل المثال، في الخطوات المذكورة أعلاه، أنشأنا عنوان URL التالي، المخصص للمستخدم للنقر عليه والانتقال إلى الصفحة المقابلة:

https://example.com/step2.html?orig_user_id=$amp_client_id

ومع ذلك، فمن الممكن تمامًا أن يقوم المستخدم أو أحد المهاجمين بتغيير عنوان URL هذا ليكون:

https://example.com/step2.html?orig_user_id=$malicious_value

تريد التأكد من أنك لا تعالج سوى مثيلات $amp_client_id وتجنب استخدام مثيلات $malicious_value.

الخطوات المقترحة للتحقق من صحة القيم اللتي تم استلامها عبر معلمات طلب بحث عنوان URL: تأكد من مطابقة مرجع الصفحة المقصودة لعنوان URL الذي تتوقع رؤيته. يجب أن يكون هذا عادةً ما رأيته يحمل قيمة معرّف سبق رؤيتها في طلب صالح لمشاركة الموارد عبر المصادر (CORS). نوُصي بقبول مثل هذه المعرفات المعروفة فقط.

على إحدى الصفحات التي لا تدعم AMP، تحقق من مرجع المستند مباشرةً من جانب العميل أو مرِّر القيمة كجزء من اختبار ping للتحليلات لتتمكّن من التحقق من صحة جانب الخادم. إذا كانت قيمة المرجع واحدة يمكنك الوثوق بها، فيمكنك قبول القيم التي نشأت من عنوان URL للصفحة المقصودة ومعالجتها، مثل orig_user_id في المثال الوارد أعلاه.

على إحدى صفحات AMP، استخدم المتغير البديل مرجع المستند substitution لتمرير قيمة المرجع كجزء من اختبار ping للتحليلات. المعالجة من جانب الخادم هي الخيار الوحيد المتوفر. للتوضيح، في ما يلي اختبار ping للتحليلات يمكن أن ترسله الصفحة المقصودة والذي يحتوي على (1) قيمة معرّف العميل للصفحة الحالية، (2) قيمة تم تمريرها من خلال عنوان URL الذي أعددناه ليكون قيمة معرّف العميل في الإحالة الصفحة و(3) معلومات المرجع نفسها للتحقق من قيمة (2): https://analytics.example.com/ping?type=pageview&orig_user_id=${queryParam(ref_id)}&user_id=${clientId(uid)}&referrer=${documentReferrer}

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

الممارسات الموُصى بها بشدة

الاحتفاظ باقتران واحد فقط

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

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

مراعاة ملفات تعريف الارتباط وحذف التخزين المحلي

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

الامتثال للقوانين واللوائح المحلية

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