Multi-Vendor Marketplace & Meta Pixel/CAPI Engineering — mystock.bg

mystock.bg is a Bulgarian multi-vendor e-commerce marketplace — built in the style of large-scale marketplace platforms, where multiple independent vendors list and sell products through a single unified storefront. Think of it as Bulgaria's version of an Amazon-style marketplace: one destination for buyers, a full vendor management layer behind it.

We built the core platform and continue to develop it — including the advanced advertising infrastructure and the internal CRM systems that keep the operation running.

Our work on mystock.bg covers three interconnected areas: the marketplace platform itself, a deep Meta Pixel and Conversions API engineering engagement that restored tracking integrity across the full purchase funnel, and an advanced vendor and office CRM system currently in active development.

The Platform

Multi-Vendor Marketplace Architecture

mystock.bg is built as a true multi-vendor marketplace — not a single-seller store with a marketplace skin, but a platform where independent vendors each manage their own product catalogues, inventory, and order fulfilment, while buyers experience a unified storefront.

The platform architecture handles:

Vendor onboarding and profiles — each vendor operates as an independent entity within the platform, with their own product listings, pricing controls, and order management view
Unified product catalogue — buyer-facing search and browsing aggregates across all vendors with consistent categorisation, filtering, and product presentation
Order routing — orders containing products from multiple vendors are split and routed to the correct vendor fulfilment queue without buyer-facing complexity
Vendor dashboards — each vendor has full visibility into their own sales, inventory levels, and order status without visibility into other vendors' data
Platform-level admin — the mystock.bg team manages vendor accounts, commission structures, dispute resolution, and platform-wide reporting from a central admin layer

Bulgarian Market Context

mystock.bg is designed specifically for the Bulgarian e-commerce market — localisation, payment methods, shipping integrations, and currency handling are all built for Bulgarian consumers and vendors rather than adapted from a generic international template.

Meta Pixel & Conversions API Engineering

The Tracking Problem

At scale, advertising tracking is not a set-and-forget configuration. It is an engineering surface that degrades — browser updates restrict cookie access, ad blockers intercept pixel events, platform deployments introduce regressions, and infrastructure configurations produce unexpected side effects that only show up as data gaps in Ads Manager.

mystock.bg was experiencing exactly this: tracking integrity issues across their Meta advertising infrastructure that were suppressing the signal quality their campaigns depended on to optimise. The problems were real, but the causes were not immediately obvious.

Diagnosis: PageView Regression

The first problem was a PageView event regression — browser-side PageView events that had previously fired correctly had stopped doing so reliably.

We traced the regression systematically:

Reproduction — confirmed the failure was consistent and scope-bounded, not intermittent
Commit bisection — worked back through the deployment history to identify exactly which commits introduced the behaviour change
Root cause isolation — identified the specific code change that broke PageView firing, confirmed it was not an environmental issue (browser, network, or Meta-side)
Fix and verification — resolved the regression at the source and verified correct PageView firing across the full site using Meta Pixel Helper and Events Manager live event stream

Fixing a regression by tracing it to its commit is the right way to solve it — patching around the symptom leaves the underlying issue in the codebase to resurface.

Cloudflare Bot Fight Mode / Google AdsBot Conflict

The second problem was a Cloudflare infrastructure conflict. Cloudflare's Bot Fight Mode — a feature designed to block automated bot traffic — was identifying and blocking Google's AdsBot crawler. AdsBot is Google's legitimate advertising crawler that validates landing pages for ad quality and eligibility; blocking it has direct downstream effects on campaign performance and ad serving.

We diagnosed and resolved this at the Cloudflare configuration level:

Confirmed AdsBot was being blocked through Cloudflare's security event logs and cross-referencing with Google's published AdsBot IP ranges and user agent strings
Identified the specific Bot Fight Mode rule responsible for the false positive
Implemented the correct Cloudflare configuration to allow AdsBot through while maintaining the Bot Fight Mode protection for actual malicious bots
Verified AdsBot crawl access was restored without weakening the broader security posture

This is a documented conflict that catches many teams — Bot Fight Mode's aggressive defaults do not distinguish between malicious bots and Google's legitimate advertising infrastructure.

Conversions API (CAPI) Implementation

To address the structural limitations of browser-only pixel tracking — increasing ad blocker rates, browser privacy restrictions, and ITP — we implemented Meta's Conversions API as a server-side parallel signal.

The CAPI implementation runs server-side event sending in parallel with the browser-side Pixel:

Browser Pixel continues to fire for real-time, client-side event capture with full browser context
CAPI sends the same events server-side, bypassing browser-level blocking and providing a more reliable, persistent signal to Meta's attribution system
Event deduplication via matching event_id values prevents double-counting in Ads Manager when both the Pixel and CAPI report the same event

Server-side sending captures events that the browser Pixel misses — blocked by ad blockers, dropped due to network issues, or not fired because the user navigates away before the browser-side script executes.

EMQ Improvement

Event Match Quality (EMQ) measures how effectively Meta can match an event back to a Facebook user for attribution. Higher EMQ means more events matched to users, which means better campaign attribution, better audience signals, and better optimisation.

We ran systematic EMQ improvement across the four highest-value purchase funnel events:

Purchase The conversion event that matters most. We audited the customer data parameters being sent with each Purchase event — email, phone, first name, last name, city, country, zip — and identified which were missing or being sent in un-hashed or incorrectly normalised form. Meta requires SHA-256 hashing of all PII parameters; incorrect normalisation before hashing (e.g. not lowercasing email addresses) produces hashes that do not match Meta's stored user data.

AddToCart High-volume upper-funnel signal for audience building and retargeting. EMQ on AddToCart was improved by adding customer data parameters at the point of cart addition — where user session data is often available even for non-authenticated users.

InitiateCheckout At checkout initiation, user identity is typically known. We ensured all available customer parameters were being passed, including email captured at the checkout email field before form submission.

AddPaymentInfo At this stage of the funnel, full customer identity is available. We verified all customer parameters were being sent server-side via CAPI with correct normalisation and hashing, providing maximum match quality for this high-intent event.

Ongoing Work — Advanced Vendor & Office CRM

What We Are Building

The mystock.bg operation has grown to a scale where its vendors and internal office team need a purpose-built CRM and management system to handle the complexity that generic tools cannot.

We are currently in active development on an advanced CRM covering two user groups:

Vendor-Facing System

Full vendor product and inventory management
Order management with status tracking and fulfilment workflow
Sales reporting and performance dashboards
Communication tools for vendor-to-platform and vendor-to-buyer interactions
Commission and payout tracking

Main Office System

Platform-wide vendor management — onboarding, account status, performance review
Cross-vendor order oversight and dispute handling
Financial reporting — commissions, payouts, platform revenue
Customer service tools for escalations that route above the vendor level
Marketing and campaign management tools tied into the advertising infrastructure we manage

The CRM is being built to match the scale and complexity of the platform — not a generic off-the-shelf tool adapted to fit, but a system designed specifically for how mystock.bg operates.

Technical Stack

| Layer | Technology | |-------|-----------| | Platform | Multi-vendor e-commerce marketplace | | Tracking | Meta Pixel (browser-side), Meta Conversions API (server-side) | | Infrastructure | Cloudflare (CDN, security, bot management) | | Event Hashing | SHA-256 customer data normalisation | | CRM (In Dev) | Custom full-stack system for vendors and office | | Market | Bulgaria — localised payments, shipping, currency |

Results

PageView regression resolved — traced to the exact commits responsible and fixed at source, not worked around
Google AdsBot unblocked — Cloudflare Bot Fight Mode conflict diagnosed and resolved at the configuration level, restoring ad quality crawl access
CAPI live and deduplicating — server-side event sending running in parallel with the browser Pixel, capturing events that browser-only tracking loses
EMQ improved across all four funnel events — Purchase, AddToCart, InitiateCheckout, and AddPaymentInfo all sending correctly normalised, correctly hashed customer data parameters for maximum match quality
Vendor CRM in active development — system designed for the real operational complexity of a multi-vendor Bulgarian marketplace

Improve your advertising tracking or build your marketplace →