A complete technical and strategic guide to building a system that connects in-store purchase data to digital ad platforms — enabling real attribution for offline retail.دليل تقني واستراتيجي شامل لبناء نظام يربط بيانات المبيعات داخل المتجر بمنصات الإعلانات الرقمية — لتحقيق إسناد إعلاني حقيقي لمبيعات التجزئة الأوفلاين.
Digital ad platforms — Meta, TikTok, Google — are built to track online behavior. When someone clicks an ad, lands on a website, and buys something, the platform sees the entire chain. Attribution is automatic.منصات الإعلانات الرقمية — Meta وTikTok وGoogle — مصممة لتتبع السلوك الأونلاين. عندما ينقر شخص على إعلان ويزور موقعًا ويشتري منتجًا، ترى المنصة السلسلة كاملة. الإسناد الإعلاني يحدث تلقائيًا.
Offline retail breaks this chain. A customer sees your ad on Instagram, walks into your store three days later, and pays cash at the register. Meta has no idea that sale happened. Your POS system has no idea the customer came from an ad. The result: you're spending money on ads with no way to measure what's actually working.مبيعات التجزئة الأوفلاين تكسر هذه السلسلة. عميل يرى إعلانك على Instagram، يدخل متجرك بعد ثلاثة أيام، ويدفع نقدًا عند الكاشير. Meta لا تعلم أن هذا البيع حدث. ونظام نقاط البيع (POS) لا يعلم أن العميل جاء من إعلان. النتيجة: أنت تنفق على الإعلانات بدون أي طريقة لقياس ما ينجح فعلًا.
This guide describes a system that closes that gap. It creates a data bridge between your point-of-sale and your ad platforms — so every in-store purchase can be attributed back to the ad that influenced it.هذا الدليل يصف نظامًا يسد هذه الفجوة. يبني جسرًا للبيانات بين نظام نقاط البيع ومنصات الإعلانات — بحيث يمكن إسناد كل عملية شراء داخل المتجر إلى الإعلان الذي أثر فيها.
It takes a purchase that happened in your physical store and sends it as a Purchase event to Meta, TikTok, and Google — with the customer's identity attached — so the ad platform can check: "Did this person see one of our ads before buying?" If yes, the sale is attributed. Your ROAS becomes real.يأخذ عملية شراء حدثت في متجرك الفعلي ويرسلها كـ حدث شراء (Purchase Event) إلى Meta وTikTok وGoogle — مع هوية العميل مرفقة — حتى تتحقق منصة الإعلانات: "هل رأى هذا الشخص أحد إعلاناتنا قبل الشراء؟" إذا نعم، يُسند البيع للإعلان. ويصبح العائد على الإنفاق الإعلاني (ROAS) حقيقيًا.
The complete system has four layers. Data moves left to right — from the physical store to the ad platform.النظام الكامل يتكون من أربع طبقات. تتحرك البيانات من المتجر الفعلي إلى منصة الإعلانات.
Your point-of-sale or ERP system is where every transaction originates. The system needs to capture three things per transaction: customer identity (name + phone number), order details (products, quantities, prices), and a unique order ID. Most modern POS systems — Shopify POS, Square, Lightspeed, Vend, or any custom ERP — can do this natively.نظام نقاط البيع أو الـ ERP هو مصدر كل معاملة. النظام يحتاج لالتقاط ثلاثة أشياء لكل معاملة: هوية العميل (الاسم + رقم الهاتف)، تفاصيل الطلب (المنتجات والكميات والأسعار)، ورقم طلب فريد. معظم أنظمة نقاط البيع الحديثة — Shopify POS وSquare وLightspeed وVend أو أي ERP مخصص — تدعم ذلك أساسًا.
This is the hardest part of the system. Ad platforms can only attribute a sale if they can match the buyer's identity to someone who saw an ad. The capture layer creates a reason for the offline customer to interact with a digital touchpoint — opening a URL, scanning a QR code, connecting to WiFi — where either a browser pixel fires or their identity is captured for server-side API submission.هذا هو الجزء الأصعب في النظام. منصات الإعلانات لا تستطيع إسناد عملية بيع إلا إذا استطاعت مطابقة هوية المشتري مع شخص رأى إعلانًا. طبقة الالتقاط تخلق سببًا للعميل الأوفلاين للتفاعل مع نقطة اتصال رقمية — فتح رابط، مسح QR code، الاتصال بالـ WiFi — حيث يعمل بيكسل المتصفح أو يتم التقاط هويته لإرسالها عبر واجهة برمجة السيرفر.
There are 8 methods to do this. Each one has a single goal: get a Purchase event fired with the customer's order data attached.هناك 8 طرق لتحقيق ذلك. كل طريقة لها هدف واحد: إطلاق حدث شراء (Purchase Event) مع بيانات طلب العميل مرفقة.
Once the customer interacts with a digital touchpoint, the system fires a Purchase event through one or both channels:بمجرد تفاعل العميل مع نقطة الاتصال الرقمية، يُطلق النظام حدث شراء عبر إحدى القناتين أو كلتيهما:
Meta, TikTok, and Google receive the Purchase event and check their records: "Did this person (identified by cookie, phone hash, or email hash) see or click one of this advertiser's ads in the attribution window?" If yes — the sale is attributed. If no — it's recorded as an organic purchase. Either way, your ad platform now knows about the sale.تستقبل Meta وTikTok وGoogle حدث الشراء وتتحقق من سجلاتها: "هل هذا الشخص (المحدد عبر cookie أو هاش الهاتف أو هاش الإيميل) رأى أو نقر على أحد إعلانات هذا المعلن خلال نافذة الإسناد؟" إذا نعم — يُسند البيع. إذا لا — يُسجل كشراء عضوي. في كلتا الحالتين، منصة الإعلانات أصبحت تعلم بعملية البيع.
There are two ways to send a Purchase event to ad platforms. These are delivery methods — how the data gets there. Both send the same event; they just travel different roads.هناك طريقتان لإرسال حدث الشراء إلى منصات الإعلانات. هذه هي طرق التوصيل — كيف تصل البيانات. كلاهما يرسل نفس الحدث، لكن عبر مسارات مختلفة.
The customer opens a URL on their phone. A JavaScript pixel on that page fires a Purchase event. The pixel reads browser cookies to identify the user and match them to prior ad interactions.العميل يفتح رابطًا على هاتفه. بيكسل JavaScript على الصفحة يُطلق حدث شراء. البيكسل يقرأ ملفات تعريف الارتباط (cookies) لتحديد هوية المستخدم ومطابقته مع تفاعلاته السابقة مع الإعلانات.
How the match happens: The pixel reads cookies like _fbp (Meta), _ttp (TikTok), or _gcl_aw (Google) that were set when the customer first interacted with an ad. It sends these along with the Purchase event.كيف تتم المطابقة: البيكسل يقرأ ملفات الارتباط مثل _fbp (Meta) و_ttp (TikTok) و_gcl_aw (Google) التي تم إنشاؤها عند أول تفاعل للعميل مع إعلان. ويرسلها مع حدث الشراء.
Your server sends the Purchase event directly to the ad platform's API — no browser involved. The platform matches the customer using hashed identifiers: phone number, email, or both.السيرفر يرسل حدث الشراء مباشرة إلى API منصة الإعلانات — بدون متصفح. المنصة تطابق العميل باستخدام معرّفات مشفرة: رقم الهاتف، الإيميل، أو كليهما.
How the match happens: You hash the customer's phone/email with SHA-256 and send it via the API. The platform checks: "Do we have a user with this hashed phone who saw an ad?" Deterministic — no cookies needed.كيف تتم المطابقة: تشفّر هاتف/إيميل العميل بخوارزمية SHA-256 وترسله عبر الـ API. المنصة تتحقق: "هل لدينا مستخدم بهذا الهاتف المشفر رأى إعلانًا؟" مطابقة حتمية — بدون ملفات ارتباط.
| Browser Pixelبيكسل المتصفح | Server APIواجهة برمجة السيرفر | |
|---|---|---|
| Where it runsأين يعمل | In the customer's browserفي متصفح العميل | On your serverعلى السيرفر |
| Matching methodطريقة المطابقة | Cookies (probabilistic)ملفات ارتباط (احتمالية) | Phone/email hash (deterministic)هاش الهاتف/الإيميل (حتمية) |
| Match rateنسبة المطابقة | 40–55% | 65–85% |
| Blocked by ad blockersيحجبه مانع الإعلانات | Yesنعم | Noلا |
| Affected by iOS privacyيتأثر بخصوصية iOS | Yes (cookie restrictions)نعم (قيود ملفات الارتباط) | Noلا |
| Requires customer actionيتطلب تفاعل العميل | Yes (must open a URL)نعم (يجب فتح رابط) | No (server sends automatically)لا (السيرفر يرسل تلقائيًا) |
| Setup complexityتعقيد الإعداد | Low — install JS snippetمنخفض — تثبيت كود JavaScript | Medium — requires server/middlewareمتوسط — يتطلب سيرفر/وسيط |
| Real-time?لحظي؟ | Yes — fires instantlyنعم — يُطلق فورًا | Near-real-time (seconds to minutes)شبه لحظي (ثوانٍ إلى دقائق) |
| Best forالأفضل لـ | Customers who open your linksالعملاء الذين يفتحون روابطك | All customers (even those who don't)جميع العملاء (حتى من لا يفتحون) |
Browser pixel and server API are complementary, not alternatives. The pixel captures cookie-based matches from customers who open links. The API captures identity-based matches for all customers, even those who never click. Use the event_id parameter on both to prevent double-counting. Details in Section 07.بيكسل المتصفح وواجهة برمجة السيرفر مكملان لبعضهما، وليسا بديلين. البيكسل يلتقط المطابقات عبر ملفات الارتباط من العملاء الذين يفتحون الروابط. الـ API يلتقط المطابقات عبر الهوية لـجميع العملاء، حتى من لم ينقروا أبدًا. استخدم معامل event_id في كليهما لمنع الاحتساب المزدوج. التفاصيل في القسم 07.
event_id — platform deduplicates automaticallyكلا المسارين يرسلان نفس event_id — المنصة تمنع التكرار تلقائيًاSeparately from how you send the event (browser vs server), there's what type the ad platform classifies it as. This matters for how the platform reports and optimizes.بشكل منفصل عن كيفية إرسال الحدث (متصفح vs سيرفر)، هناك نوع التصنيف الذي تعطيه منصة الإعلانات. وهذا يؤثر على كيفية إعداد التقارير والتحسين.
When an ad platform receives a Purchase event, it classifies it into one of two categories. This classification changes how the event appears in your reporting and how the algorithm uses it for optimization.عندما تستقبل منصة إعلانات حدث شراء، تصنفه في إحدى فئتين. هذا التصنيف يغير كيفية ظهور الحدث في تقاريرك وكيف تستخدمه الخوارزمية للتحسين.
The platform treats this as a standard e-commerce purchase — someone saw an ad, visited your website, and bought online. This is the default when a browser pixel fires a Purchase event.المنصة تتعامل مع هذا كـعملية شراء تجارة إلكترونية قياسية — شخص رأى إعلانًا، زار موقعك، واشترى أونلاين. هذا هو الافتراضي عند إطلاق بيكسل المتصفح لحدث شراء.
Attribution model: Standard click/view attribution. 7-day click, 1-day view window. The platform assumes the purchase happened right when the event fired.نموذج الإسناد: إسناد قياسي للنقر/المشاهدة. نافذة 7 أيام للنقر، يوم واحد للمشاهدة. المنصة تفترض أن الشراء حدث لحظة إطلاق الحدث.
When to use: When the browser pixel fires on your landing page. Even though your customer bought in-store, the pixel-fired event looks like an online event to the platform. This is fine — attribution still works because the cookie matches to an ad.متى تستخدمه: عندما يعمل بيكسل المتصفح على صفحة الهبوط. حتى لو اشترى عميلك من المتجر، حدث البيكسل يبدو كحدث أونلاين للمنصة. هذا مقبول — الإسناد يعمل لأن ملف الارتباط يتطابق مع الإعلان.
The platform treats this as an in-store purchase — someone saw an ad and later bought at a physical location. This event type has its own reporting column and attribution model.المنصة تتعامل مع هذا كـشراء من المتجر — شخص رأى إعلانًا واشترى لاحقًا من موقع فعلي. هذا النوع له عمود تقارير ونموذج إسناد خاص به.
Attribution model: Extended attribution window. Platforms allow more time between ad exposure and purchase because physical store visits naturally lag. Some platforms use store-visit modeling on top.نموذج الإسناد: نافذة إسناد ممتدة. المنصات تمنح وقتًا أطول بين التعرض للإعلان والشراء لأن زيارات المتجر الفعلي تتأخر بطبيعتها. بعض المنصات تستخدم نمذجة زيارات المتجر إضافيًا.
When to use: When your server sends the event via the Conversions API. Set action_source to "physical_store" (Meta) or the equivalent offline channel type (TikTok/Google). This tells the platform to apply the correct offline attribution model.متى تستخدمه: عندما يرسل السيرفر الحدث عبر واجهة التحويلات (CAPI). اضبط action_source على "physical_store" (Meta) أو نوع القناة الأوفلاين المكافئ (TikTok/Google). هذا يخبر المنصة بتطبيق نموذج الإسناد الأوفلاين الصحيح.
| Online Conversionتحويل أونلاين | Offline Conversionتحويل أوفلاين | |
|---|---|---|
| How it appears in Ads Managerكيف يظهر في مدير الإعلانات | Under "Purchases" (standard column)تحت "Purchases" (العمود القياسي) | Under "Offline Purchases" (separate column)تحت "Offline Purchases" (عمود منفصل) |
| Attribution windowنافذة الإسناد | 7-day click, 1-day view (standard)7 أيام نقر، يوم واحد مشاهدة (قياسي) | Extended — up to 28 days depending on platformممتدة — حتى 28 يومًا حسب المنصة |
| Optimization signalإشارة التحسين | Platform uses it like any website conversionالمنصة تستخدمه كأي تحويل موقع | Platform applies store-visit modeling + offline attribution logicالمنصة تطبق نمذجة زيارات المتجر + منطق الإسناد الأوفلاين |
| ROAS calculationحساب ROAS | Included in standard ROASيُدرج في ROAS القياسي | Included in offline ROAS — some platforms show a blended viewيُدرج في ROAS الأوفلاين — بعض المنصات تعرض عرضًا مدمجًا |
| action_source | "website" | "physical_store" |
| Sent fromيُرسل من | Browser pixel (or CAPI with action_source: website)بيكسل المتصفح (أو CAPI مع action_source: website) | Server API with action_source: physical_storeواجهة برمجة السيرفر مع action_source: physical_store |
Both — and here's why. Your browser pixel fires an online conversion (action_source: website) because it runs in the customer's browser. Your server API fires an offline conversion (action_source: physical_store) because it comes from your POS data. With event_id deduplication, the platform receives both, keeps one, and uses whichever has better matching data. In practice: the server-side offline event usually wins because it carries the hashed phone number for deterministic matching.كلاهما — وإليك السبب. بيكسل المتصفح يُطلق تحويلًا أونلاين (action_source: website) لأنه يعمل في متصفح العميل. واجهة برمجة السيرفر تُطلق تحويلًا أوفلاين (action_source: physical_store) لأنه يأتي من بيانات نظام نقاط البيع. مع منع التكرار عبر event_id، المنصة تستقبل كليهما، تحتفظ بواحد، وتستخدم الذي لديه بيانات مطابقة أفضل. عمليًا: حدث السيرفر الأوفلاين يفوز عادة لأنه يحمل هاش رقم الهاتف للمطابقة الحتمية.
Browser vs Server = how you send the data (Section 02). Online vs Offline = how the ad platform classifies and reports the event (this section). A server API can send an "online" event (action_source: "website") and a browser pixel technically fires as an "online" event even if the purchase happened in a physical store. The action_source field is what actually controls the classification.المتصفح vs السيرفر = كيف ترسل البيانات (القسم 02). أونلاين vs أوفلاين = كيف تصنف منصة الإعلانات الحدث وتعرضه في التقارير (هذا القسم). واجهة برمجة السيرفر يمكنها إرسال حدث "أونلاين" (action_source: "website") وبيكسل المتصفح تقنيًا يُطلق كحدث "أونلاين" حتى لو حدث الشراء في متجر فعلي. حقل action_source هو ما يتحكم فعليًا في التصنيف.
Eight methods to get the offline customer's data into the system. Every method fires one event: Purchase. The method is just the vehicle — the destination is always the same.ثماني طرق لإدخال بيانات العميل الأوفلاين إلى النظام. كل طريقة تُطلق حدثًا واحدًا: Purchase. الطريقة هي مجرد الوسيلة — الوجهة دائمًا واحدة.
The fundamental constraint: ad platforms need either a browser cookie or a hashed identifier (phone/email) to match a purchase to an ad. The capture methods below solve this by creating a moment where the customer either opens a URL (browser pixel fires) or provides their phone number (server API sends). Most methods do both.القيد الأساسي: منصات الإعلانات تحتاج إما ملف ارتباط متصفح أو معرّف مشفر (هاتف/إيميل) لمطابقة عملية شراء بإعلان. طرق جمع البيانات أدناه تحل هذا بخلق لحظة يقوم فيها العميل إما بفتح رابط (البيكسل يعمل) أو بتقديم رقم هاتفه (السيرفر يرسل). معظم الطرق تحقق كليهما.
The SMS contains a personalized URL with the order ID. The landing page pulls the order data and fires a Purchase event with value, currency, and product IDs. The customer's phone number is also sent server-side via CAPI as a backup.الرسالة القصيرة تحتوي على رابط مخصص برقم الطلب. صفحة الهبوط تسحب بيانات الطلب وتُطلق حدث شراء بالقيمة والعملة ومعرّفات المنتجات. رقم هاتف العميل يُرسل أيضًا من جانب السيرفر عبر CAPI كنسخة احتياطية.
The QR URL encodes the order ID or is dynamically generated per transaction. When scanned, the landing page loads the order data from your backend and fires the Purchase event. Offer a discount on next visit as incentive to scan.رابط الـ QR يحتوي على رقم الطلب أو يتم إنشاؤه ديناميكيًا لكل معاملة. عند المسح، صفحة الهبوط تحمّل بيانات الطلب من السيرفر وتُطلق حدث الشراء. قدّم خصمًا على الزيارة القادمة كحافز للمسح.
The captive portal page has the pixel installed. When the customer enters their phone, your server looks up the most recent transaction from that phone number in the same branch and fires the Purchase event via CAPI with the order value.صفحة البوابة فيها البيكسل مثبت. عندما يدخل العميل رقم هاتفه، السيرفر يبحث عن أحدث معاملة لهذا الرقم في نفس الفرع ويُطلق حدث الشراء عبر CAPI بقيمة الطلب.
The loyalty form runs in a browser on a store tablet. The pixel fires immediately. The phone number is matched to the transaction the cashier just processed, and the Purchase event includes the full order value retroactively.نموذج الولاء يعمل في متصفح تابلت المتجر. البيكسل يعمل فورًا. رقم الهاتف يُطابق مع المعاملة التي أتمها الكاشير للتو، وحدث الشراء يتضمن قيمة الطلب الكاملة بأثر رجعي.
Identical to SMS but through WhatsApp — which has significantly higher open rates in MENA, South Asia, and LatAm. The URL contains the order ID. The landing page loads the transaction and fires the Purchase event.مطابقة لطريقة SMS لكن عبر WhatsApp — الذي يتمتع بمعدلات فتح أعلى بكثير في منطقة الشرق الأوسط وشمال أفريقيا وجنوب آسيا وأمريكا اللاتينية. الرابط يحتوي على رقم الطلب. صفحة الهبوط تحمّل المعاملة وتُطلق حدث الشراء.
The survey link contains the order ID. The pixel fires the Purchase event the moment the page loads — the customer doesn't even need to complete the survey. The feedback is a bonus; the attribution happens on page load.رابط الاستبيان يحتوي على رقم الطلب. البيكسل يُطلق حدث الشراء لحظة تحميل الصفحة — العميل لا يحتاج حتى لإكمال الاستبيان. التقييم مكافأة إضافية؛ الإسناد الإعلاني يحدث عند تحميل الصفحة.
The registration form captures the phone number and product serial. Your backend matches the serial to the POS transaction, and the Purchase event fires with the full order value. Self-motivated — customers want warranty protection.نموذج التسجيل يلتقط رقم الهاتف والرقم التسلسلي للمنتج. السيرفر يطابق الرقم التسلسلي مع معاملة نظام نقاط البيع، ويُطلق حدث الشراء بقيمة الطلب الكاملة. دافع ذاتي — العملاء يريدون حماية الضمان.
The highest capture rate method. The tablet is part of the checkout flow — the cashier says "enter your number for your digital receipt." The pixel fires on the store's own device. No dependency on the customer's phone, no links to open.أعلى طريقة في معدل الالتقاط. التابلت جزء من عملية الدفع — الكاشير يقول "دخّل رقمك لإيصالك الرقمي." البيكسل يعمل على جهاز المتجر نفسه. لا اعتماد على هاتف العميل، لا روابط لفتحها.
Method 1 (SMS) + Method 8 (Tablet) cover 50–70% of your customers with minimal friction. Add Method 2 (QR) + Method 5 (WhatsApp) in month 2 for another 20–30%.الطريقة 1 (SMS) + الطريقة 8 (التابلت) تغطي 50–70% من عملائك بأقل احتكاك. أضف الطريقة 2 (QR) + الطريقة 5 (WhatsApp) في الشهر الثاني لتغطية 20–30% إضافية.
How data flows from the moment a transaction is recorded to the moment the ad platform receives the Purchase event.كيف تتدفق البيانات من لحظة تسجيل المعاملة إلى لحظة استقبال منصة الإعلانات لحدث الشراء.
The critical design decision in this pipeline is step 3: generating the event_id. This ID must be the same across both the browser pixel and the server-side API. When both fire (which is the goal), the ad platform uses this ID to deduplicate — ensuring the purchase is counted once, not twice.القرار التصميمي الحاسم في هذا الخط هو الخطوة 3: إنشاء event_id. هذا المعرّف يجب أن يكون متطابقًا في كل من بيكسل المتصفح وواجهة برمجة السيرفر. عندما يعملان معًا (وهو الهدف)، تستخدم منصة الإعلانات هذا المعرّف لمنع التكرار — لضمان احتساب الشراء مرة واحدة فقط.
The server-side API call (Path B) should fire immediately after the POS webhook — within seconds. The browser pixel (Path A) fires whenever the customer opens the link, which could be minutes or hours later. Both are valid. The platform accepts events within its attribution window (typically 7 days for clicks, 1 day for views).استدعاء واجهة برمجة السيرفر (المسار ب) يجب أن يُطلق فورًا بعد webhook نظام نقاط البيع — خلال ثوانٍ. بيكسل المتصفح (المسار أ) يعمل عندما يفتح العميل الرابط، وقد يكون ذلك بعد دقائق أو ساعات. كلاهما صالح. المنصة تقبل الأحداث ضمن نافذة الإسناد (عادة 7 أيام للنقرات، يوم واحد للمشاهدات).
Installing tracking pixels on your landing pages so they fire Purchase events when customers open links.تثبيت بيكسلات التتبع على صفحات الهبوط لإطلاق أحداث الشراء عند فتح العملاء للروابط.
Every landing page (receipt page, QR page, survey page, WiFi portal) needs three pixel base codes installed in the <head>. All three coexist on the same page:كل صفحة هبوط (صفحة الإيصال، صفحة QR، صفحة الاستبيان، بوابة WiFi) تحتاج ثلاثة أكواد بيكسل أساسية مثبتة في <head>. الثلاثة تتواجد على نفس الصفحة:
// Base pixel (install once in <head>)
fbq('init', 'YOUR_PIXEL_ID');
// Fire Purchase event with order data
fbq('track', 'Purchase', {
value: 1240.00,
currency: 'EGP',
content_ids: ['SKU-POLO-001', 'SKU-SNKR-042'],
content_type: 'product',
order_id: 'ORD-28401'
}, { eventID: 'evt_28401_1711640520' });
ttq.track('CompletePayment', {
value: 1240.00,
currency: 'EGP',
contents: [
{ content_id: 'SKU-POLO-001', quantity: 2, price: 240 },
{ content_id: 'SKU-SNKR-042', quantity: 1, price: 620 }
]
}, { event_id: 'evt_28401_1711640520' });
gtag('event', 'purchase', {
transaction_id: 'ORD-28401',
value: 1240.00,
currency: 'EGP',
items: [
{ item_id: 'SKU-POLO-001', quantity: 2, price: 240 },
{ item_id: 'SKU-SNKR-042', quantity: 1, price: 620 }
]
});
The landing page URL contains the order ID as a parameter:رابط صفحة الهبوط يحتوي على رقم الطلب كمعامل:
https://track.yourbrand.com/receipt?order=ORD-28401On page load, the page calls your backend API with this order ID, receives the full transaction data (customer, items, value), and fires the Purchase events above. The customer sees a formatted receipt. The pixels fire in the background.عند تحميل الصفحة، تستدعي الصفحة API السيرفر برقم الطلب، وتستقبل بيانات المعاملة الكاملة (العميل، المنتجات، القيمة)، وتُطلق أحداث الشراء أعلاه. العميل يرى إيصالًا منسقًا. البيكسلات تعمل في الخلفية.
Sending Purchase events directly from your server to ad platforms — no browser required, higher match rates, works for every customer.إرسال أحداث الشراء مباشرة من السيرفر إلى منصات الإعلانات — بدون متصفح، نسب مطابقة أعلى، يعمل لكل عميل.
Browser pixels have a fundamental limitation: they only fire if the customer opens a link. Even with the best capture methods, 30–50% of customers will never open your SMS or scan your QR code. Server-side API calls fire for every single transaction — the moment it's recorded in your POS — regardless of whether the customer interacts with any link.بيكسلات المتصفح لديها قيد أساسي: لا تعمل إلا إذا فتح العميل رابطًا. حتى مع أفضل طرق الالتقاط، 30–50% من العملاء لن يفتحوا رسالتك القصيرة أو يمسحوا QR code أبدًا. استدعاءات واجهة برمجة السيرفر تعمل لـكل معاملة بدون استثناء — لحظة تسجيلها في نظام نقاط البيع — بغض النظر عن تفاعل العميل مع أي رابط.
Additionally, browser-based matching is degrading due to iOS privacy changes, ad blockers, and third-party cookie deprecation. Server-side matching uses hashed phone numbers and emails — deterministic identifiers that aren't affected by browser restrictions.بالإضافة لذلك، المطابقة عبر المتصفح تتدهور بسبب تغييرات خصوصية iOS ومانعات الإعلانات وإيقاف ملفات الارتباط من الطرف الثالث. المطابقة من جانب السيرفر تستخدم أرقام هواتف وإيميلات مشفرة — معرّفات حتمية لا تتأثر بقيود المتصفح.
Send hashed phone + email. SHA-256 required before sending. Include event_id for dedup with browser pixel.أرسل هاش الهاتف + الإيميل. التشفير بـ SHA-256 مطلوب قبل الإرسال. ضمّن event_id لمنع التكرار مع بيكسل المتصفح.
POST graph.facebook.com
/v21.0/{pixel_id}/eventsSimilar structure. Send event type, user data (hashed), and purchase properties. Include event_id for dedup.بنية مشابهة. أرسل نوع الحدث، بيانات المستخدم (مشفرة)، وخصائص الشراء. ضمّن event_id لمنع التكرار.
POST business-api.tiktok.com
/open_api/v1.3/pixel/track/Upload hashed customer data. Google matches server-side. Can also batch-upload via Google Ads UI.ارفع بيانات العميل المشفرة. Google يطابق من جانب السيرفر. يمكن أيضًا الرفع المجمّع عبر واجهة Google Ads.
POST googleads.googleapis.com
/v18/customers/{id}
:uploadOfflineConversions{
"data": [{
"event_name": "Purchase",
"event_time": 1711640520,
"event_id": "evt_28401_1711640520",
"action_source": "physical_store",
"user_data": {
"ph": ["a1b2c3...sha256_hash_of_phone"],
"fn": ["e4d5f6...sha256_hash_of_first_name"],
"ln": ["g7h8i9...sha256_hash_of_last_name"],
"country": ["eg"]
},
"custom_data": {
"value": 1240.00,
"currency": "EGP",
"content_ids": ["SKU-POLO-001", "SKU-SNKR-042"],
"content_type": "product",
"order_id": "ORD-28401"
}
}]
}
This field tells Meta that the purchase happened in a physical store, not online. Meta uses this to apply the correct attribution model for offline events. For TikTok, use "offline" as the channel type. For Google, the upload type itself indicates offline.هذا الحقل يخبر Meta أن الشراء حدث في متجر فعلي، وليس أونلاين. Meta تستخدم هذا لتطبيق نموذج الإسناد الصحيح للأحداث الأوفلاين. لـ TikTok، استخدم "offline" كنوع القناة. لـ Google، نوع الرفع نفسه يشير إلى أوفلاين.
When you fire the same Purchase event through both the browser pixel and the server API, the ad platform needs to know it's one purchase — not two.عندما تُطلق نفس حدث الشراء عبر بيكسل المتصفح وواجهة برمجة السيرفر معًا، منصة الإعلانات تحتاج أن تعرف أنها عملية شراء واحدة — وليست اثنتين.
Every Purchase event — whether fired by the browser pixel or the server API — must include the same event_id. This is a string you generate, typically by combining the order ID with the event timestamp:كل حدث شراء — سواء أُطلق من بيكسل المتصفح أو واجهة برمجة السيرفر — يجب أن يتضمن نفس event_id. هذا نص تُنشئه أنت، عادة بدمج رقم الطلب مع الطابع الزمني:
event_id = "evt_" + order_id + "_" + unix_timestamp
// Example: "evt_28401_1711640520"| Scenarioالسيناريو | What Happensماذا يحدث | Resultالنتيجة |
|---|---|---|
| Customer opens link AND server sendsالعميل يفتح الرابط والسيرفر يرسل | Platform receives two events with same event_idالمنصة تستقبل حدثين بنفس event_id | Counted onceيُحسب مرة — dedup works — منع التكرار يعمل |
| Customer never opens link, server sendsالعميل لا يفتح الرابط أبدًا، السيرفر يرسل | Platform receives one event (server only)المنصة تستقبل حدثًا واحدًا (سيرفر فقط) | Counted onceيُحسب مرة — server covers it — السيرفر يغطيه |
| Customer opens link, server failsالعميل يفتح الرابط، السيرفر يفشل | Platform receives one event (pixel only)المنصة تستقبل حدثًا واحدًا (بيكسل فقط) | Counted onceيُحسب مرة — pixel covers it — البيكسل يغطيه |
Deduplication makes it safe to fire from both channels. There's no risk of double-counting. But there IS a risk of under-counting if you only use one channel. Browser pixel alone misses non-openers. Server API alone misses cookie-based matching. Both together = maximum attribution coverage.منع التكرار يجعل الإطلاق من كلتا القناتين آمنًا. لا يوجد خطر احتساب مزدوج. لكن يوجد خطر نقص في الاحتساب إذا استخدمت قناة واحدة فقط. بيكسل المتصفح وحده يفوّت من لا يفتحون. واجهة برمجة السيرفر وحدها تفوّت المطابقة عبر ملفات الارتباط. كلاهما معًا = أقصى تغطية للإسناد الإعلاني.
The exact fields sent in every Purchase event — across all platforms and both channels.الحقول المحددة المرسلة في كل حدث شراء — عبر جميع المنصات وكلتا القناتين.
| Fieldالحقل | Typeالنوع | Descriptionالوصف | Exampleمثال |
|---|---|---|---|
| event_name | string | Always "Purchase"دائمًا "Purchase" | Purchase |
| event_id | string | Unique ID for deduplicationمعرّف فريد لمنع التكرار | evt_28401_1711640520 |
| event_time | integer | Unix timestamp of purchaseالطابع الزمني Unix للشراء | 1711640520 |
| action_source | string | "physical_store" for offline"physical_store" للأوفلاين | physical_store |
| value | float | Total order valueإجمالي قيمة الطلب | 1240.00 |
| currency | string | ISO 4217 currency codeكود العملة ISO 4217 | EGP |
| order_id | string | Your POS order referenceمرجع طلب نظام نقاط البيع | ORD-28401 |
| content_ids | array | Product SKUs in the orderأكواد المنتجات في الطلب | ["SKU-POLO-001"] |
| content_type | string | Type of contentنوع المحتوى | product |
All user data must be SHA-256 hashed before sending. Lowercase and trim whitespace before hashing.جميع بيانات المستخدم يجب تشفيرها بـ SHA-256 قبل الإرسال. حوّل للأحرف الصغيرة وأزل المسافات قبل التشفير (Hashing).
| Fieldالحقل | Typeالنوع | Descriptionالوصف | Hash Requiredالتشفير مطلوب |
|---|---|---|---|
| ph | string | Phone number (E.164 format)رقم الهاتف (صيغة E.164) | SHA-256 |
| em | string | Email address (lowercase)البريد الإلكتروني (أحرف صغيرة) | SHA-256 |
| fn | string | First name (lowercase)الاسم الأول (أحرف صغيرة) | SHA-256 |
| ln | string | Last name (lowercase)اسم العائلة (أحرف صغيرة) | SHA-256 |
| country | string | ISO country codeكود الدولة ISO | SHA-256 |
Send as many user fields as you have. Phone alone gives ~50% match rate. Phone + email gives ~70%. Phone + email + name + country gives ~80%+. The more identifiers you send, the more confident the platform's match.أرسل أكبر عدد ممكن من حقول المستخدم. الهاتف وحده يعطي ~50% نسبة مطابقة. الهاتف + الإيميل يعطي ~70%. الهاتف + الإيميل + الاسم + الدولة يعطي ~80%+. كلما أرسلت معرّفات أكثر، زادت ثقة المنصة في المطابقة.
If you operate more than one store location, the system needs to track which branch each purchase came from — so you can measure performance per location.إذا كنت تدير أكثر من موقع متجر، النظام يحتاج لتتبع من أي فرع جاء كل شراء — حتى تتمكن من قياس الأداء لكل موقع.
Without branch tagging, all your store purchases get lumped into one pool. You can't tell which ad campaigns are driving sales to which location. You can't allocate budget intelligently. You can't identify underperforming branches. Branch-level tracking transforms your data from "we made EGP 1.98M this month" into "Mall of Arabia generated EGP 485K at 9.4x ROAS, while District 5 generated EGP 170K at 6.8x ROAS."بدون وسم الفروع، كل مشتريات متاجرك تُجمع في مجموعة واحدة. لا يمكنك معرفة أي حملات إعلانية تقود المبيعات لأي موقع. لا يمكنك تخصيص الميزانية بذكاء. لا يمكنك تحديد الفروع ضعيفة الأداء. تتبع مستوى الفرع يحوّل بياناتك من "حققنا 1.98 مليون ج.م هذا الشهر" إلى "مول العرب حقق 485 ألف ج.م بـ ROAS 9.4x، بينما ديستريكت 5 حقق 170 ألف ج.م بـ ROAS 6.8x."
Your POS system should include a branch_id or store_location field in every transaction record. Most multi-location POS systems do this natively. If yours doesn't, configure it — this is the foundation everything else is built on.نظام نقاط البيع يجب أن يتضمن حقل branch_id أو store_location في كل سجل معاملة. معظم أنظمة نقاط البيع متعددة المواقع تفعل ذلك أساسًا. إذا لم يكن كذلك، اضبطه — هذا هو الأساس الذي يُبنى عليه كل شيء.
Every Purchase event — whether sent via browser pixel or server API — should include the branch identifier in the custom data payload. For Meta, use the content_category or a custom property. For Google, use the store_code field.كل حدث شراء — سواء أُرسل عبر بيكسل المتصفح أو واجهة برمجة السيرفر — يجب أن يتضمن معرّف الفرع في حمولة البيانات المخصصة. لـ Meta، استخدم content_category أو خاصية مخصصة. لـ Google، استخدم حقل store_code.
fbq('track', 'Purchase', {
value: 1240.00,
currency: 'EGP',
content_ids: ['SKU-POLO-001'],
content_category: 'mall_of_arabia', // branch identifier
order_id: 'ORD-28401'
});
Create separate ad campaigns (or ad sets) per branch, each geo-targeted to a radius around that physical location. Use UTM parameters to tag which branch the campaign targets:أنشئ حملات إعلانية منفصلة (أو مجموعات إعلانية) لكل فرع، كل منها مستهدفة جغرافيًا لنطاق حول ذلك الموقع الفعلي. استخدم معاملات UTM لوسم أي فرع تستهدفه الحملة:
utm_term=branch_mall_of_arabia
utm_term=branch_city_centre_almazaWith branch tagging in place, you can build reporting that shows per-branch metrics:مع وسم الفروع في مكانه، يمكنك بناء تقارير تعرض مؤشرات كل فرع:
| Branchالفرع | Ad Spendالإنفاق الإعلاني | Attributed Revenueالإيرادات المُسندة | ROAS | Actionالإجراء |
|---|---|---|---|---|
| Branch Aالفرع أ | EGP 12K12 ألف ج.م | EGP 112K112 ألف ج.م | 9.4x | Scale budget +20%زد الميزانية +20% |
| Branch Bالفرع ب | EGP 10K10 آلاف ج.م | EGP 68K68 ألف ج.م | 6.8x | Maintain, test new creativesحافظ، جرّب تصميمات جديدة |
| Branch Cالفرع ج | EGP 8K8 آلاف ج.م | EGP 19K19 ألف ج.م | 2.4x | Review targeting, reduce budgetراجع الاستهداف، قلل الميزانية |
One POS integration handles all locations. One middleware server. Manual branch tagging is fine. You can manage campaigns per branch in a single ad account. Weekly reporting in a spreadsheet works.تكامل POS واحد يتعامل مع جميع المواقع. سيرفر وسيط واحد. الوسم اليدوي للفروع كافٍ. يمكنك إدارة الحملات لكل فرع في حساب إعلاني واحد. تقارير أسبوعية في جدول بيانات تعمل.
Automated branch tagging becomes essential. Consider a centralized dashboard for cross-branch reporting. Campaign structure needs clear naming conventions. Budget allocation rules should be automated based on ROAS thresholds.الوسم الآلي للفروع يصبح ضروريًا. فكّر في لوحة تحكم مركزية لتقارير عبر الفروع. هيكل الحملات يحتاج اصطلاحات تسمية واضحة. قواعد تخصيص الميزانية يجب أن تُؤتمت بناءً على حدود ROAS.
You need a dedicated middleware platform (not custom scripts). Automated budget reallocation. Branch-level anomaly detection (if a branch's match rate drops, alert immediately). Consider separate ad accounts per region.تحتاج منصة وسيطة مخصصة (وليس سكربتات مخصصة). إعادة تخصيص ميزانية آلية. كشف الشذوذ على مستوى الفرع (إذا انخفضت نسبة المطابقة لفرع، تنبيه فوري). فكّر في حسابات إعلانية منفصلة لكل منطقة.
Enterprise-grade setup. Centralized data lake for all POS data. API-first architecture. Automated campaign creation per new branch. Real-time dashboards. Dedicated operations team or a platform like Avamartech to manage the system.إعداد على مستوى المؤسسات. مستودع بيانات مركزي لجميع بيانات POS. بنية API-first. إنشاء حملات آلي لكل فرع جديد. لوحات تحكم لحظية. فريق عمليات مخصص أو منصة مثل Avamartech لإدارة النظام.
You don't need to write code. But you do need to make decisions, provide access, and manage the operational side. Here's the split.لا تحتاج لكتابة كود. لكنك تحتاج لاتخاذ قرارات، وتوفير الصلاحيات، وإدارة الجانب التشغيلي. إليك التقسيم.
Based on your customer behavior: Do they respond to SMS? Is WhatsApp more natural? Can your cashiers handle a tablet at checkout? Start with 2 methods, expand based on data.بناءً على سلوك عملائك: هل يستجيبون لـ SMS؟ هل WhatsApp أكثر طبيعية؟ هل يستطيع الكاشير التعامل مع تابلت عند الدفع؟ ابدأ بطريقتين، ووسّع بناءً على البيانات.
Cashiers need to know what to say: "Can I have your number for the digital receipt?" or "Scan this QR for 10% off next visit." The system only works if the staff participates.الكاشير يحتاج يعرف ماذا يقول: "ممكن رقمك للإيصال الرقمي؟" أو "امسح الـ QR لخصم 10% على زيارتك الجاية." النظام لا يعمل إلا إذا شارك الموظفون.
Your technical team needs: POS admin access (to configure webhooks), Meta Business Manager access, TikTok Ads access, Google Ads access. You grant the permissions; they do the setup.فريقك التقني يحتاج: صلاحية مدير POS (لضبط webhooks)، صلاحية Meta Business Manager، صلاحية TikTok Ads، صلاحية Google Ads. أنت تمنح الصلاحيات؛ هم ينفذون الإعداد.
Decide on a subdomain like track.yourbrand.com and point it to wherever your technical team tells you. This takes 5 minutes in your domain registrar.حدد نطاقًا فرعيًا مثل track.yourbrand.com ووجّهه حيث يخبرك فريقك التقني. هذا يستغرق 5 دقائق في مسجّل النطاقات.
Your technical team builds the reports; you read them. Key questions: Which branches are performing? Which capture methods have the best rates? Is ROAS above target? Where should we spend more?فريقك التقني يبني التقارير؛ أنت تقرأها. الأسئلة الرئيسية: أي فروع تؤدي جيدًا؟ أي طرق التقاط لديها أفضل المعدلات؟ هل ROAS فوق المستهدف؟ أين يجب أن ننفق أكثر؟
Based on the data, decide how to allocate ad budget across branches and platforms. The system gives you the numbers; you make the call.بناءً على البيانات، حدد كيف توزع ميزانية الإعلانات عبر الفروع والمنصات. النظام يعطيك الأرقام؛ أنت تتخذ القرار.
Configure the POS to send transaction data to the middleware server via webhooks. This is platform-specific and requires API access.ضبط نظام نقاط البيع لإرسال بيانات المعاملات إلى السيرفر الوسيط عبر webhooks. هذا خاص بكل منصة ويتطلب صلاحية API.
Create the receipt page, QR landing page, survey page, and WiFi portal page — all with tracking pixels installed and dynamic order data loading.إنشاء صفحة الإيصال، صفحة هبوط QR، صفحة الاستبيان، وصفحة بوابة WiFi — جميعها ببيكسلات تتبع مثبتة وتحميل بيانات طلب ديناميكي.
Build and maintain the server that receives POS webhooks, triggers capture methods (SMS, WhatsApp), and sends server-side API events to ad platforms.بناء وصيانة السيرفر الذي يستقبل webhooks نظام نقاط البيع، ويُشغّل طرق الالتقاط (SMS، WhatsApp)، ويرسل أحداث API من جانب السيرفر لمنصات الإعلانات.
Install browser pixels, set up Conversions API tokens, configure TikTok Events API, set up Google Enhanced Conversions. Handle SHA-256 hashing and event deduplication.تثبيت بيكسلات المتصفح، إعداد رموز واجهة التحويلات (CAPI)، ضبط TikTok Events API، إعداد Google Enhanced Conversions. التعامل مع التشفير بـ SHA-256 ومنع تكرار الأحداث.
Integrate with Twilio, MessageBird, or a local SMS provider. Set up WhatsApp Business API templates. Manage message delivery and failure handling.التكامل مع Twilio أو MessageBird أو مزود SMS محلي. إعداد قوالب WhatsApp Business API. إدارة توصيل الرسائل ومعالجة الأخطاء.
Monitor match rates, event delivery status, webhook failures, and pixel health. Fix issues before they affect attribution accuracy.مراقبة نسب المطابقة، حالة توصيل الأحداث، أعطال webhooks، وصحة البيكسل. إصلاح المشاكل قبل أن تؤثر على دقة الإسناد الإعلاني.
This system involves server infrastructure, API integrations, data hashing, and pixel debugging. If you don't have a technical team in-house, hire a developer, an agency, or use a platform like Avamartech that handles the technical layer for you. Your job is the business decisions — which branches, which methods, which budgets. Let technical people handle the plumbing.هذا النظام يتضمن بنية تحتية للسيرفرات، تكاملات API، تشفير بيانات، وتصحيح أخطاء البيكسل. إذا لم يكن لديك فريق تقني داخلي، وظّف مطورًا، أو وكالة، أو استخدم منصة مثل Avamartech تتولى الطبقة التقنية نيابة عنك. مهمتك هي قرارات الأعمال — أي فروع، أي طرق، أي ميزانيات. دع التقنيين يتعاملون مع البنية التحتية.
All code snippets, API endpoints, and technical examples in this document are illustrative only. They show the structure and logic of the implementation — not production-ready code. API versions, field names, and authentication methods change frequently.جميع مقتطفات الكود ونقاط الـ API والأمثلة التقنية في هذا المستند هي توضيحية فقط. تعرض هيكل ومنطق التطبيق — وليست كودًا جاهزًا للإنتاج. إصدارات API وأسماء الحقول وطرق المصادقة تتغير باستمرار.
The technical implementation should only be done by a qualified developer, agency, or technical partner who can verify current API documentation, handle authentication, error handling, data security, and compliance requirements (including GDPR/data privacy if applicable).التطبيق التقني يجب أن يتم فقط بواسطة مطور مؤهل أو وكالة أو شريك تقني يستطيع التحقق من وثائق API الحالية، والتعامل مع المصادقة، ومعالجة الأخطاء، وأمن البيانات، ومتطلبات الامتثال (بما في ذلك GDPR/خصوصية البيانات إن وُجدت).
Always refer to the official documentation for the latest API versions: Meta for Developers, TikTok for Business Developers, and Google Ads API documentation.ارجع دائمًا للوثائق الرسمية لأحدث إصدارات API: Meta for Developers وTikTok for Business Developers وGoogle Ads API documentation.
Follow these steps in order. Each step depends on the previous one being complete.اتبع هذه الخطوات بالترتيب. كل خطوة تعتمد على اكتمال الخطوة السابقة.
Register a subdomain like track.yourbrand.com. Point it to your server or landing page host. This is where all pixel pages will live.سجّل نطاقًا فرعيًا مثل track.yourbrand.com. وجّهه إلى السيرفر أو مضيف صفحات الهبوط. هنا ستتواجد جميع صفحات البيكسل.
Add the base snippet for each platform to the <head> of your landing page template. Verify each fires a PageView in the respective platform's Event Manager.أضف الكود الأساسي لكل منصة في <head> قالب صفحة الهبوط. تحقق من أن كل واحد يُطلق PageView في مدير الأحداث الخاص بالمنصة.
Create a dynamic page at track.yourbrand.com/receipt?order=ORDER_ID. It should: (1) call your backend to fetch the order data, (2) display a formatted receipt, (3) fire Purchase events on all three pixels with the order data.أنشئ صفحة ديناميكية على track.yourbrand.com/receipt?order=ORDER_ID. يجب أن: (1) تستدعي السيرفر لجلب بيانات الطلب، (2) تعرض إيصالًا منسقًا، (3) تُطلق أحداث Purchase على البيكسلات الثلاث ببيانات الطلب.
Set up your POS to send a webhook (HTTP POST) to your server every time a transaction is completed. The payload must include: customer phone, customer name, order ID, line items, and total value.اضبط نظام نقاط البيع لإرسال webhook (HTTP POST) إلى السيرفر عند كل معاملة مكتملة. الحمولة يجب أن تتضمن: هاتف العميل، اسم العميل، رقم الطلب، بنود الطلب، والقيمة الإجمالية.
This server receives POS webhooks and does three things: (1) generates an event_id, (2) triggers the capture method (SMS, WhatsApp, etc.) with a personalized URL, (3) sends the Purchase event via server-side APIs to Meta, TikTok, and Google.هذا السيرفر يستقبل webhooks نظام نقاط البيع ويقوم بثلاثة أشياء: (1) يُنشئ event_id، (2) يُشغّل طريقة الالتقاط (SMS، WhatsApp، إلخ.) برابط مخصص، (3) يرسل حدث الشراء عبر واجهات برمجة السيرفر إلى Meta وTikTok وGoogle.
Integrate with an SMS provider (Twilio, MessageBird, or a local provider). Configure the middleware to send an SMS to the customer's phone with the receipt URL after every transaction.تكامل مع مزود SMS (Twilio أو MessageBird أو مزود محلي). اضبط السيرفر الوسيط لإرسال SMS لهاتف العميل برابط الإيصال بعد كل معاملة.
Generate a CAPI access token in Events Manager. Configure your middleware to send Purchase events with hashed user data and the event_id to the Meta CAPI endpoint.أنشئ رمز وصول CAPI في مدير الأحداث. اضبط السيرفر الوسيط لإرسال أحداث Purchase ببيانات مستخدم مشفرة وevent_id إلى نقطة نهاية Meta CAPI.
Repeat the server-side setup for TikTok and Google. Use the same event_id across all platforms and both channels (browser + server).كرر إعداد جانب السيرفر لـ TikTok وGoogle. استخدم نفس event_id عبر جميع المنصات وكلتا القناتين (متصفح + سيرفر).
Make a test purchase. Verify: (1) POS webhook fires, (2) SMS arrives with correct link, (3) opening the link shows the receipt page, (4) Purchase events appear in all three platform Event Managers, (5) server-side events also appear, (6) deduplication works (one event, not two).أجرِ عملية شراء تجريبية. تحقق من: (1) webhook نظام نقاط البيع يعمل، (2) SMS يصل بالرابط الصحيح، (3) فتح الرابط يعرض صفحة الإيصال، (4) أحداث Purchase تظهر في مدير الأحداث للمنصات الثلاث، (5) أحداث السيرفر تظهر أيضًا، (6) منع التكرار يعمل (حدث واحد، وليس اثنين).
Add QR codes at checkout, set up WhatsApp Business API, deploy tablets at high-traffic locations. Each method uses the same receipt page and the same event_id system.أضف QR codes عند الكاشير، أعدّ WhatsApp Business API، انشر تابلتات في المواقع عالية الحركة. كل طريقة تستخدم نفس صفحة الإيصال ونفس نظام event_id.
In each ad platform, create a custom conversion for your offline Purchase event. Set your campaigns to optimize for this conversion. Allow a 7-day click attribution window.في كل منصة إعلانية، أنشئ تحويلًا مخصصًا لحدث الشراء الأوفلاين. اضبط حملاتك للتحسين لهذا التحويل. اسمح بنافذة إسناد نقر 7 أيام.
Track match rates in each platform's Event Manager. If match rates are below 50%, send more user data fields (email, name). If capture rates are low, test different SMS copy, QR placement, or add more methods.تتبع نسب المطابقة في مدير الأحداث لكل منصة. إذا كانت نسب المطابقة أقل من 50%، أرسل حقول بيانات مستخدم أكثر (إيميل، اسم). إذا كانت معدلات الالتقاط منخفضة، جرّب نصوص SMS مختلفة، أو أماكن QR مختلفة، أو أضف طرقًا أخرى.