تتجه تجارة AI نحو البروتوكولات. Google وShopify وOpenAI وStripe يعملون على أجزاء مختلفة من agentic commerce. هذا ضروري. إذا كان AI سيكتشف المنتجات، يجهز السلة، يساعد في الدفع، ويقرب المستخدم من الشراء، فالسوق يحتاج إلى واجهات مشتركة.
لكن البروتوكولات لا تحل مشكلة القياس تلقائيا. UCP وACP وAP2 لها أدوار مهمة. لا يوجد واحد منها يجيب وحده عن السؤال الكامل: ماذا أوصى AI، كم زيارة بشرية جلبت هذه التوصية، ماذا فعل الزوار، وأي إيراد يمكن نسبته بدليل؟
ما الذي تغطيه البروتوكولات
UCP قريب من merchant discovery وcapability declaration. التاجر يعلن بشكل قابل للقراءة الآلية ما الذي يستطيع دعمه: cart، checkout، discounts، subscriptions أو catalog.
ACP أقرب إلى تنفيذ checkout وبيانات المعاملة. يهتم بكيفية ربط شراء داخل تجربة AI بأنظمة التاجر والدفع.
AP2 يعالج التفويض والثقة في الدفع. mandates وcredentials توضح ما الذي سمح به المستخدم وفي أي نطاق يستطيع agent أن يتصرف.
كل هذه الطبقات مفيدة. لكنها ليست سلسلة attribution كاملة.
المرحلة | البروتوكول / الإطار | ما يمكن رصده |
|---|---|---|
AI discovery (استعلام الكتالوج) | UCP | ما المنتجات والشروط التي استعلم عنها agent |
AI recommendation (الإجابة) | AIAA Answer | هل ذكر AI العلامة، كيف وصفها، وهل أوصى بها |
Agent fetch (جلب المعلومات) | AIAA Request | ما الصفحات التي قرأها agent، وكم مرة وبأي عمق |
وصول المستخدم (AI referral) | AIAA Visit | من أي AI جاء المستخدم، أين هبط، ماذا فعل |
نية تجارية | AIAA Commerce | السلة، المقارنة، بدء checkout |
AI checkout (تنفيذ المعاملة) | ACP | تفاصيل checkout وحالة الدفع |
AI authorization (ثقة الدفع) | AP2 | توقيعات التفويض وسلسلة التدقيق |
Revenue attribution | AIAA Attribution | هل يمكن تفسير الإيراد كمصدره AI |
يوضح الجدول أن البروتوكول والدليل ليسا الشيء نفسه. UCP يجعل المنتجات والقدرات قابلة للقراءة، لكنه لا يخبر تلقائيا أي إجابة AI أوصت بالعلامة. ACP ينظم checkout، لكنه لا يحفظ كل سياق discovery. AP2 يقوي التفويض والثقة، لكنه لا يستبدل دليل الرحلة والإيراد.
لذلك يجب أن تبني العلامات طبقة دليل مستقلة عن البروتوكول الفائز: بيانات منتج قابلة للقراءة، مراقبة الإجابات، logs للوكلاء، AI referrers، أحداث التجارة، orders وCRM. إذا أصبح بروتوكول ما مهيمنا، ستزداد قيمة هذه الطبقة لا تقل.
كلما زادت standardization زادت الحاجة إلى القياس. عندما تقترب الوكلاء من cart وpayment وAPIs التشغيلية، تحتاج legal وfinance وproduct وmarketing إلى معرفة ما الفعل الذي تم تفويضه، وما التوصية التي سبقته، وأي revenue يمكن الدفاع عنه.
لذلك ليست الأولوية القريبة هي توقع الفائز في حرب البروتوكولات. يجب أن تجهز العلامات بيانات المنتج وFAQ والأسعار والشحن والإرجاع والحالات العملية بشكل قابل للقراءة الآلية. ويجب أن ترصد إجابات AI وطلبات الوكلاء وAI referrers والزيارات البشرية بشكل منفصل. ثم تربط commerce events وorders وCRM وpaid media touchpoints. هذا العمل يبقى مفيدا حتى لو تغير البروتوكول المهيمن.
إذا انتشر معيار شبيه بـ UCP، تصبح قابلية القراءة أهم. إذا انتشر معيار شبيه بـ ACP، يصبح سياق checkout أهم. إذا انتشر AP2، تصبح authorization أسهل في التدقيق. في الحالات الثلاث يبقى سؤال الدليل مفتوحا: أي توصية أدت إلى أي فعل وأي revenue؟
في العمل اليومي، لا يكفي أن تظهر هذه الأدلة في تقرير شهري متأخر. سياق إجابات AI يتغير بسرعة، ووتيرة قراءة agents للصفحات تختلف من صفحة إلى أخرى. يجب معرفة أي صفحات منتج، أي صفحات مقارنة، أي FAQ، أي سياسات شحن وإرجاع، وأي دراسات حالة يقرأها AI فعلا. من دون هذه الرؤية يتحول تحسين AI commerce إلى تخمين. البروتوكول قد يفتح الطريق، لكن إدارة النمو تحتاج إلى سجل مستمر لما قرأه AI، وما عرضه للمستخدم، وما حوله إلى زيارة أو فعل تجاري.
هناك خطأ آخر: التعامل مع AI referral كأنه referral عادي فقط. المستخدم قد يقرأ ملخص AI ثم يفتح الموقع مباشرة. وقد يبحث عن اسم العلامة في نافذة أخرى. وقد تصل إجابة AI إلى فريق شراء أو قناة داخلية قبل أن يظهر أي referrer واضح. لذلك لا يكفي الاعتماد على رأس referrer وحده. يجب ربط visibility داخل الإجابات، وagent requests، وسلوك landing page، وأدلة الطلبات وCRM. عندها فقط يمكن التمييز بين ظهور بلا أثر تجاري، وظهور بدأ رحلة شراء حقيقية.
AIAA ليس عدادا بسيطا لعدد مرات الظهور داخل AI. ما يهم الإدارة هو هل ساهم AI في revenue، في أي فئة أو سوق، وبأي دليل يمكن الدفاع عنه أمام finance أو legal أو قيادة الشركة. إذا ركزت الشركة على visibility فقط، قد تحصل على ظهور أكثر من دون تفسير تجاري. وإذا ركزت على protocol فقط، قد تمر transaction من دون تعلم. طبقة الدليل بينهما هي ما يجعل AI commerce قابلا للإدارة، لا مجرد تجربة تقنية.
فجوة الدليل
في الأعلى توجد أدوات GEO وAI Visibility. تقيس هل تظهر العلامة في إجابات AI، وهل توصف بدقة، وهل يتم اقتباسها. في الأسفل توجد أدوات attribution التقليدية. تربط الإيراد بالقنوات والجلسات وCRM.
الفجوة في الوسط. ماذا حدث بعد ذكر العلامة؟ ما الصفحات التي قرأتها الوكلاء؟ أي توصيات جلبت زيارات بشرية؟ أي زيارات أنتجت أحداثا تجارية؟ أي طلبات يمكن ربطها بدليل يمكن الدفاع عنه؟
لا طرف واحد يملك هذه الرؤية كاملة. منصات AI لا تملك كل طلبات المتاجر. منصات التجارة لا تعرف كل إجابة AI. بروتوكولات الدفع لا تملك كل سياق الاكتشاف. لذلك نحتاج إلى طبقة دليل مستقلة.
AIAA لا يستبدل البروتوكولات
AIAA لا ينافس UCP أو ACP أو AP2. إنه لغة قياس بين هذه الطبقات. Answer وRequest وVisit وCommerce وAttribution ترتب الأدلة من AI discovery إلى revenue.
العلامات لا يجب أن تنتظر فوز بروتوكول واحد. AI يقرأ ويقارن ويوصي الآن. المهمة هي ربط أدلة الموقع، logs، AI referrers، أحداث التجارة، orders وCRM.
رؤية Gravity عملية: البروتوكولات تبني الطرق. AIAA يسجل ما يحدث على هذه الطرق. من دون هذا السجل، قد تصبح تجارة AI ممكنة تقنيا، لكنها صعبة الإدارة تجاريا.
FAQ
Q1: ما دور UCP وACP وAP2؟
A: UCP للاكتشاف والقدرات، ACP للcheckout وبيانات التجارة، AP2 للتفويض والثقة في الدفع.
Q2: هل تحل البروتوكولات attribution؟
A: لا. تساعد في التنفيذ، لكنها لا تثبت السلسلة الكاملة من توصية AI إلى الزيارة والإيراد.
Q3: هل تكفي أدوات GEO؟
A: لا. GEO يقيس الجزء الأعلى من الرؤية. السلوك التجاري والإيراد يحتاجان إلى بيانات أخرى.
Q4: ماذا تفعل الشركة الآن؟
A: تجمع أدلة الموقع، logs، AI referrers، orders وCRM بشكل منفصل ثم تربطها.
Q5: أين يدخل AIAA؟
A: يرتب الأدلة بين AI discovery وطلبات الوكلاء والزيارات البشرية وcommerce وattribution.