For AI agents: the complete documentation index is available at https://docs.clickmax.io/en/llms.txt, the full documentation bundle is available at https://docs.clickmax.io/en/llms-full.txt, and this page is available as Markdown at https://docs.clickmax.io/en/guides/pixel-server-side-events.md.
  • English
  • Why do some events reach Meta even when the visitor has an ad blocker?

    Because those events never leave the visitor's browser. Clickmax sends them from its own servers to Meta, through the Conversions API — the visitor can have an ad blocker, have declined cookies or closed the tab before the event fired, and the conversion still arrives.

    That is why Meta's conversion total can end up higher than any tool that measures from the browser alone. It is not double counting: it is the share the browser could never report.

    Before you start

    • This applies to Meta pixels. Google Ads only receives events from the browser.
    • Server-side sending requires Use Conversions API turned on and a valid Access token on the pixel.
    • For the full list of events and each Meta event name, see which events Clickmax sends to my pixel.

    The two paths of an event

    PathWho sends itDepends on the visitor
    BrowserThe pixel code on the pageYes — an ad blocker, declined cookies or a closed tab stop the event
    Conversions APIClickmax serversNo

    When the same event goes through both paths, Clickmax sends the same event identifier on both ends and Meta counts one conversion. You do not need to turn either channel off.

    What the Conversions API can send that the browser cannot

    Some facts about your business simply do not happen while a page is open — and until now they never reached Meta:

    EventHappens whenWhy the browser could not do it
    PurchaseThe payment is approved — only the first charge; a subscription renewal does not countPix and bank slips are confirmed hours later, with the visitor long gone
    StartTrialA trial period startsThe confirmation comes from payment processing, not from a click
    SubscribeThe subscription is activatedActivation also comes from payment processing
    LeadSomeone becomes a leadIncludes leads that arrive through an integration, never touching your page
    ScheduleA booking is confirmedThe confirmation can arrive through another channel
    ContactThe lead talks to your businessWhatsApp conversations, answered calls and opened emails happen off-site
    Purchase (or the event you choose)An opportunity is won in a pipeline bound to the pixelThe sale is closed by your team, away from any page — see send a sale closed in the pipeline
    The event chosen on the stageA contact enters a pipeline stage that has a pixel eventThe stage change happens in the CRM — see send a conversion when a contact enters a stage

    PageView and ViewContent still go only through the browser. They are the highest-volume, lowest-identification events: sending them from the server as well would burn your ad account quota without improving attribution.

    A subscription renewal is not a purchase

    When a subscription renews, the next cycle's charge is not sent as Purchase. Only the first charge counts as a purchase. A renewal is not an effect of the ad — the person was already a customer —, and counting it every month would teach the campaign to look for people who already bought instead of new customers.

    Where Meta understands each event happened

    Each event carries where the fact happened, so Meta treats each one the right way:

    EventMeta receives it as
    Purchase, trial, subscription, form lead, booking, redirect link click, webinarA website event, with the address of the page where it happened
    Lead that came through a capture linkAn event from another source — the lead came from a system of yours, not from a Clickmax page
    Conversation startedA chat event; when the person came from a click-to-WhatsApp ad, a conversation from that ad
    Answered callA phone call event
    Email link clickAn email event
    Won opportunity and pipeline stageAn event recorded by the CRM, in the format Meta uses for lead stages

    The time sent is the time of the fact — the purchase, the capture, the click —, not the time the delivery went out. Meta only accepts events from the last 7 days; a delivery delayed beyond that is not made and shows as Not sent in the pixel's Delivery history, without taking the other events down with it.

    Click-to-WhatsApp ads

    When the contact's most recent ad click in the last 7 days was on a click-to-WhatsApp ad, the conversation started and the contact's CRM events (won opportunity, pipeline stage) go to Meta as conversions from that ad, not as a page visit.

    For that, the WhatsApp number that received the conversation must be connected to Clickmax with its WhatsApp Business account identified. On Meta's side, the pixel's dataset must be linked to the same WhatsApp Business account in Events Manager — without it Meta cannot tie the conversation to the ad. When the WhatsApp Business account is missing, the event goes as a regular chat.

    What each event needs in order to actually arrive

    Three conditions, all on the pixel:

    • Being turned on for that pixel. A pixel you create starts with every event turned on. A pixel that came from the old per-product setup keeps exactly the events it already had — the new ones stay off until you turn them on, so a live campaign does not have its optimisation baseline changed under it.
    • Having the Access token. Without Use Conversions API turned on and a valid token, the event only goes through the browser. This is the most common cause of "Meta never got my Pix sale".
    • Passing the event's own filters. Purchase respects Payment method: if you unchecked Pix, a sale paid with Pix produces no event on either path.

    Data quality on each path

    Server-side sending carries what the person filled in at checkout (email, phone, tax ID, address), which helps Meta recognise who converted. Whatever checkout lacks — like the ad click when the person pays the Pix after leaving the page — is filled in from the contact. For events that start outside checkout — lead, booking, contact, won opportunity — it carries whatever the contact has: email, phone, city and state from the record, the most recent Meta ad click on any device the contact was recognized on (including from before they identified themselves, and the one from the very visit where they filled in the form) and the browser identifier Meta’s pixel created on your pages. The more complete the contact, the better the attribution.

    The phone goes with the country code — a Brazilian mobile saved without 55 gets it added. City and state go in the format Meta compares ("Minas Gerais" becomes MG). Meta also receives the same contact identifier on all of the contact's events, from lead to purchase, so it can tie them together.

    CRM events (won opportunity, pipeline stage), calls and conversations do not carry the browser or internet address of an old visit of the contact: they did not happen in a browser.

    An event sent from the server does not show up in tools that inspect the page, such as Meta Pixel Helper: it never went through the browser. To check it, use Meta Events Manager — the walkthrough is in how to test that my pixel is really firing.