أضف المحفظة إلى منظومتك أم انتقل إلى منصة أخرى؟

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

كتبنا هذا المقال للفرق التي تعمل على منصات مثل Braze أو OneSignal أو CleverTap وتريد بطاقات المحفظة دون هدم كل شيء. وللمقارنة على مستوى المزوّدين، راجع مقارنة بطاقات المحفظة.

من أين تبدأ

يختلف دعم المحفظة كثيراً بين منصات التفاعل. تضيف Braze المحفظة عبر شركاء مثل PassKit. ولا تقدّم OneSignal بطاقات محفظة أصلية. راجع الوثائق الحالية لمنصتك قبل التخطيط، لأن هذا يتغير.

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

وفي منطقة الشرق الأوسط وشمال أفريقيا، حيث تتجاوز حصة Android ‏70%، لا يكفي أن تدعم الأداة بطاقات Apple وحدها. تحقق أولاً من أن الطريق الذي تختاره يُصدر بطاقات Google Wallet بالجودة نفسها، لأن معظم عملائك سيحفظون البطاقة على Android.

الطريق A: احتفظ بمنصة CEP وأضف أداة بطاقات

تحتفظ بمنصتك الحالية للإشعارات الفورية والبريد الإلكتروني والشرائح، وتربط أداة بطاقات مستقلة لـ Apple Wallet وGoogle Wallet.

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

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

أما العيب فيتراكم مع الوقت. قاعدتا بيانات تحتاجان إلى مزامنة، واشتراكان، ومراجعتان للأمان وGDPR. وكل سيناريو يجمع بين تحديث البطاقة ورسالة، مثل «نقاطك ستنتهي قريباً»، يُبنى عبر أداتين.

الطريق B: انتقل إلى منصة بمحفظة أصلية

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

تُصدر البطاقات حسب معرّف المستخدم (User ID) داخل المنصة. فترى الشرائح والرحلات والقنوات حامل البطاقة عميلاً واحداً. خطوة واحدة في الرحلة تُصدر البطاقة، والخطوة التالية ترسل الرابط.

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

التكلفة هي الانتقال نفسه: تغييرات SDK، واستيراد البيانات، وإعادة بناء الرحلات والقوالب. ويؤتي ثماره عندما تكون المحفظة قناة طويلة الأمد، لا حملة لمرة واحدة.

إطار اتخاذ القرار

قيّم وضعك على 4 أسئلة.

إذا كانت إجابتان أو أكثر من إجاباتك «طويلة الأمد» أو «الكثير» أو «لا مطورين» أو «معالجون أقل»، فانظر بجدية إلى الطريق B. وإن لم تكن أي منها كذلك، فالطريق A خيار جيد تماماً، ويمكنك مراجعته بعد عام.

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

حساب تكلفة الأداتين

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

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

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

قائمة التحقق للانتقال

إذا اخترت الطريق B، فخطّط للانتقال حول العميل، لا حول الأداة.

• راجع ما ترسله. اجمع في قائمة حملات الإشعارات الفورية والبريد الإلكتروني وSMS والرسائل داخل التطبيق، والرحلات والشرائح التي يجب نقلها.
• اربط بياناتك. معرّفات المستخدمين والوسوم (tags) والأحداث وسجلات الموافقة. معرّف المستخدم هو ما يربط البطاقة بالعميل.
• أعدّ المحفظة مرة واحدة. شهادة Pass Type ID من Apple (حساب Apple Developer بتكلفة $99 سنوياً) وIssuer ID من Google مع دعوة حساب الخدمة الخاص بـ Pushwoosh إلى حساب المُصدِر.
• ادمج SDK. استبدل SDK القديم في تطبيقك واختبر الإشعارات الفورية قبل نقل الحركة.
• أعد بناء الرحلات الأساسية أولاً. الترحيب، ثم السلة المتروكة، ثم استعادة العملاء، ثم سيناريوهات المحفظة الجديدة.
• خطّط لإطلاق البطاقات. أصدر البطاقات من خطوة في الرحلة وأرسل الرابط عبر البريد الإلكتروني أو SMS أو الإشعار الفوري.
• شغّل المنصتين معاً لفترة قصيرة. احتفظ بالمنصة القديمة لفترة تداخل قصيرة، ثم أوقفها.

أثناء الانتقال، استخدم API لإصدار البطاقات من نظامك الخلفي.

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

بسّط منظومتك مع Pushwoosh

يُصدر Pushwoosh بطاقات Apple Wallet وGoogle Wallet الأصلية على معرّف المستخدم والشرائح والرحلات نفسها التي تعمل عليها الإشعارات الفورية والرسائل داخل التطبيق والبريد الإلكتروني وSMS وWhatsApp. إنها منصة واحدة، مستضافة على بنيتها التحتية الخاصة في ألمانيا والولايات المتحدة، ومتوافقة مع GDPR وحاصلة على SOC 2 Type 2. اطّلع على موقع Pushwoosh بين خيارات المحفظة.

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

الأسئلة الشائعة