Meta events Omnikyo sends
Omnikyo sends five types of events to Meta: page views, product views, cart additions, checkout opens, and purchases. Each event fires from both the browser and server, but Meta counts them once using an event ID.
বাংলায়: Page view থেকে Purchase পর্যন্ত পাঁচ ধরনের event Meta-এ পৌঁছায়। প্রতিটি event দুই পথে যায় — শপারের ব্রাউজার থেকে এবং Omnikyo সার্ভার থেকে। একই event দুইবার এলেও Meta একবার গণনা করে বিশেষ "event ID" ব্যবহার করে।
Events table
| Event | When fired | Browser | Server | What it includes |
|---|---|---|---|---|
| PageView | Every page load | Yes | Yes | No custom data |
| ViewContent | Product page viewed | Yes | Yes | Product ID, product name, price, currency |
| AddToCart | Item added to cart | Yes | Yes | Item price × quantity = value, product ID |
| InitiateCheckout | Checkout page loaded with items | Yes | Yes | Cart total value, number of items, product IDs |
| Purchase | Order placed (COD) or paid (bKash) | Browser only (COD) | Always | Order ID, order total, all items, customer data hashed, currency |
PageView has no extra data — just "a page was viewed". ViewContent, AddToCart, and InitiateCheckout carry the value (price in Taka) and product IDs so Meta can optimize ads by product. Purchase carries the customer's email, phone, name and city (all hashed), so Meta can match the order back to the person who saw the ad.
Events are batched and sent every ~15 seconds or when the page closes. The browser window or tab closing triggers a final "page leaving" send.
Limits and safety
- At most 20 events per request. If a visitor's browser queues more than 20 events before sending, they are split into multiple requests.
- Event value is clamped between 0 and 10,000,000 Taka. A nonsense value (negative, over 10 million, or non-numeric) becomes 0 or the ceiling.
- String fields (product names, etc.) are capped at 512 characters. Product IDs are capped at 128.
- Custom data (product arrays, etc.) can have at most 20 keys and at most 50 items in an array.
- An event timestamp from the browser is trusted only if it is within the last 10 minutes. Older or future times are replaced with the server's "now".
- If a browser event was queued but not sent for more than 15 seconds (e.g., the page was backgrounded), Meta still receives it, but older timestamps are used.
Event deduplication
The same event can fire from both the browser pixel and Omnikyo's server. Meta de-duplicates using the event ID — if the same event name and the same event ID arrive twice, Meta counts it once.
The browser pixel generates a unique event ID when it fires an event (e.g., ViewContent_a1b2c3d4_1726857234567). That same ID is sent to Omnikyo's server in the browser request. Omnikyo's server mirrors the event to Meta with the same ID. Meta sees the same event_id + event_name twice and counts it as one conversion.
For COD and bKash orders, the Purchase event ID is always Purchase_<order-number>_created (e.g., Purchase_#1042_created). If the browser also fires a Purchase (COD only), it uses the same ID. Meta collapses both into one conversion. Sending the same Purchase twice (e.g., retrying after an error) does not create duplicate conversions because the ID is the same.
If your store has two Meta pixels on the page (your own old pixel code plus Omnikyo's), every event fires twice with different event IDs, and Meta counts both. This inflates your numbers. Remove the old pixel code before enabling Omnikyo's pixel.
Event match quality: what Omnikyo sends with Purchase
The Purchase event carries the most customer data. Meta uses this data to "match" the order back to the person who saw your ad — the better the data, the better the match.
Data sent with every Purchase
| Field | Hashed | Notes |
|---|---|---|
| Yes (SHA-256) | If the customer entered an email at checkout | |
| Phone | Yes (SHA-256) | Bangladeshi phone number, normalized (leading zeros removed, country code not included) |
| First name | Yes (SHA-256) | First word of the customer's name |
| Last name | Yes (SHA-256) | Rest of the name |
| City | Yes (SHA-256) | Only letters kept; numbers and punctuation removed |
| Client IP address | No (plain) | The shopper's IP; only for COD orders (not bKash) |
| Client user agent | No (plain) | Browser type and version; only for COD orders |
| _fbc cookie | No (plain) | Meta click ID, if the shopper came from a Meta ad |
| _fbp cookie | No (plain) | Meta browser ID; helps Meta track the visitor |
| Order ID | No (plain) | Your order number (e.g., #1042) |
| Order total | No | Total amount in Taka |
| Items | No | Product IDs and quantities in the order |
Hashing means Meta cannot see the real email or phone, but can recognize the same customer across orders. Omnikyo uses SHA-256 hashing and sends lowercase, trimmed values.
Differences by payment method
For cash on delivery (COD): The browser also fires a Purchase event after the order is placed, with the visitor's IP and browser info (user agent). Omnikyo's server fires another Purchase with the same event ID. Both carry hashed customer data. Match quality is high because the server has the shopper's real IP and browser.
For bKash: The browser does not fire a Purchase (the transaction is not complete yet). Omnikyo's server sends Purchase only when the payment settles, with hashed customer data but without IP or user agent. No browser event fires to match it to the visitor's session. Match quality is lower because Meta has less browser context.
For orders from your own website: The helper sends the visitor's IP, browser, and _fbp / _fbc cookies from the website's session. This is the same as COD — good match quality.
What improves match quality
- Email and phone: Always provide both at checkout if possible. Hashed email is Meta's best lever for recognizing customers.
- _fbp and _fbc cookies: These come automatically when a visitor lands from a Meta ad. Omnikyo captures them. You do not need to do anything.
- IP and user agent: Captured automatically in COD orders. bKash orders lose this because payment happens later.
- Consistent name and city data: Spelling variations and abbreviations reduce matching. Encourage full names and clear city choices.
What Meta sees as "poor match" signals
- Hashed fields sent but all blank (customer entered nothing at checkout)
- For bKash: no IP or user agent because payment settled server-to-server
- Email or phone inconsistent or absent
- _fbp/_fbc cookies missing (visitor did not come from Meta or cookies are disabled)
- Very old visitor data (a 30-day-old session matched against a Purchase)
Low match quality does not break attribution; it just makes Meta's ad optimization slower. Orders are still reported as sales; they may take longer to count toward ROAS or ROI.
Events not sent
- AddPaymentInfo: No code sends this. Not used.
- Search, Lead, CompleteRegistration, custom events: Not implemented.
- Purchase from the test bench in Settings (Pixel tab → Send test events): The test bench never fires Purchase. Use a real test order in your store instead.
Omnikyo sends only the five main e-commerce events. Other tracking pixels (Google Analytics, TikTok, etc.) are not built in.
Other ways people ask this
- meta events কী কী
- pageview event fired হয় কিভাবে
- purchase event কত বার পাঠায়
- event id কেন লাগে
- duplicate event একবার গণনা হয়
- addtocart event এ কী থাকে
- bkash order এ কম ডেটা যায় কেন
- phone hash করা হয় কেন
- matching quality কী
- event limit per request
- browser and server same event twice
- events না আসলে কোথায় দেখব
Related pages
- Tracking and conversions — why both browser and server tracking matter
- Set up the Meta Pixel and Conversions API — how to enable events
Checked against the product on 2026-10-02.