We build server-side conversion tracking for Odoo ecommerce businesses running Google and Meta ads — so your conversion data reflects what actually sold, not what a browser script managed to report.
If your ad platforms and your Odoo sales orders disagree, and you’ve already tried the obvious fixes, this is the page that tells you what fixing it properly involves and what it costs. No discovery call required to find out.
First: are you sure you need this?
Three situations where you probably don’t, and we’d rather say so here than after you’ve booked a call.
Your ad spend is modest. Below roughly $5,000–10,000 a month in paid media, the cost of measurement error is usually smaller than the cost of correcting it. Live with imperfect data and revisit when you scale. That threshold isn’t a rule — it depends on your margins — but the logic is worth applying to your own numbers.
A commercial module would cover you. If you run a standard web checkout, don’t take phone or manual orders, batched sending every half hour is fine, and your consent requirements are straightforward, an off-the-shelf Odoo tracking module will likely do the job for a few hundred dollars. The established ones ship with detailed configuration documentation and per-version releases. We’ll tell you if that’s your situation.
Your problem is Odoo CRM, not Odoo ecommerce. These are different problems with different solutions, and the shared vocabulary makes them easy to mix up — see below.
Ecommerce or CRM? These are different projects
Worth settling before anything else, because the two get conflated easily — they share a vocabulary (“conversion tracking,” “server-side,” “Meta CAPI”) while describing different events, different timings, and different solutions.
| Odoo ecommerce tracking | Odoo CRM tracking | |
|---|---|---|
| What converts | A web checkout on your Odoo store | An opportunity moving to Won in your pipeline |
| Typical business | DTC / retail selling online | B2B, quoted deals, longer sales cycle |
| What you send | Purchase event with order value | Lead or conversion event at stage change |
| Timing | Seconds after payment | Days to months after the click |
| The hard part | Deduplication with the browser pixel; verifying payment before reporting | Keeping attribution alive across a long gap between click and close |
| Free option? | No — no free path covers this properly | Yes — Stape publish a free Odoo CRM app |
If you’re CRM-side, say so and we may point you at the free option. Stape’s Odoo CRM app connects pipeline stage changes to server-side tracking at no cost, and if that fits, you don’t need us.
If you’re ecommerce-side, there is currently no free path that handles web checkout properly — verified payment status, deduplication against the pixel, consent enforcement. That’s the gap this service exists to fill.
Businesses running both need both, and that’s a genuinely bigger project.
What we build
A hybrid architecture: browser tracking for engagement, server-side transmission from Odoo for transactions. The full technical explanation is here — this is what it means in delivery terms.
Identifier capture and persistence. Click IDs from Google and Meta captured server-side on landing, held in the Odoo session, written to permanent fields on the sales order at checkout. Attribution survives however long the customer takes to buy.
Server-side transmission on order confirmation. When the order reaches Sale or Done after successful payment, Odoo calls the Meta Conversions API and the Google Ads API directly. Immediately on state change, not batched on a timer.
Identity matching done correctly. Customer data normalized to each platform’s specification and SHA-256 hashed before transmission. The normalization rules have platform-specific edge cases — Gmail addresses in particular — where getting it wrong degrades match rates silently, with no error to alert you.
Deduplication. Your Odoo order reference used as the shared event ID across both tracks, so platforms recognise the browser and server signals as one sale.
Consent enforcement in the database. Consent checked server-side before any API call is constructed. Denied consent strips identifiers and PII from the payload. Google Consent Mode v2 and Meta’s Limited Data Use handled so you keep modelled measurement where you can’t keep identified measurement. A visitor-facing opt-out in your privacy policy page.
Failure handling that surfaces problems. Every API response logged against the order. Failed transmissions retried automatically on a schedule, with a bounded attempt limit. When retries are exhausted, an administrator gets emailed. Silent failure is the default state of these systems — a failed API call leaves no trace a human will notice — which is why the alerting matters more than the logging.
Manual and phone order tracking. A flag on the sales order so staff-created orders can report conversions too. Attribution falls back to hashed customer data — you recover the conversion, not the campaign path — but the sale stops being invisible.
Browser track and data layer. GTM and Meta Pixel deployed for engagement events, fed by a data layer carrying real product metadata from Odoo — SKU, brand, category, tax-inclusive price, currency — rather than scraped from the page.
What it actually costs
Most agencies in this space either hide pricing entirely behind a “contact us” form, or quote a generic industry range with no connection to actual delivered work. Neither is very useful to you.
One thing worth knowing before you get a number from anyone, including us: the cost figures you’ll find floating around are almost entirely vendor marketing. The commonly-cited “40–80 developer hours, $4,000–16,000” range for DIY implementation traces back to companies selling managed tracking platforms, with no methodology, survey, or case data behind it. We went looking for an independent source and there isn’t one.
What we can tell you honestly is the shape of the work, based on a project we delivered — without turning our own client’s scope sheet into a public rate card. It breaks down into five areas:
- Identifier capture and persistence — GCLID/FBCLID capture, session handling, and sales order field mapping.
- Server-side tracking pipeline — Meta Conversions API and Google Ads API integration, PII hashing, and event deduplication.
- Consent and privacy — server-side consent enforcement and a visitor-facing opt-out.
- Monitoring and audit — API response logging, retry logic, and failure alerting.
- Browser track and offline conversions — GTM/Pixel deployment, a proper data layer, and manual sales order tracking.
Across those areas, the largest single cost driver was testing and verification, not the integrations themselves — conversion tracking fails silently, so confirming deduplication actually deduplicates and consent states behave correctly takes real time. Any quote that doesn’t allocate serious time to this is quoting for something that will look finished and won’t be. The two API integrations (Meta and Google) were the next-largest build items. Monitoring — logging, retry, alerting — was cheap to add but is the piece most often left out of other quotes, because nothing visibly breaks without it until it already has.
What moves the number for you: catalogue size and whether products use variants, how much of your Odoo configuration is already customised, whether you run more than one website or warehouse, whether you need subscription or portal purchase tracking, and how unusual your consent requirements are. We scope against your specifics rather than a generic range.
Investment: provided as a fixed quote after the scoping conversation below, based on your actual requirements.
For comparison, an off-the-shelf Odoo tracking module costs in the low hundreds of dollars per Odoo version. If a module covers your requirements, it’s the better buy and we’ll say so.
How we work
1. Scoping conversation (free, ~45 minutes). We look at your current setup, your ad spend, your order mix, and your consent requirements. You get a straight answer on whether you need a module, a custom implementation, or nothing at all.
2. Written scope and fixed quote. A line-item breakdown specific to your project. You see exactly what you’re paying for before committing.
3. Build and test. Implementation against your staging environment, with test events verified through Google Tag Assistant and Meta’s Test Events tooling before anything goes live.
4. Go live and verify. We compare platform-reported conversions against your Odoo sales orders over the first full week and confirm the numbers reconcile.
5. Handover. Documentation of what was built, how to verify it’s working, and what to check after an Odoo upgrade.
What we’d want to know before quoting
Useful to have ready — it makes the first conversation much faster:
- Which Odoo version, and hosted where (Odoo.sh or self-hosted — see below if you’re on Odoo Online)
- Approximate monthly ad spend across Google and Meta
- Roughly what share of orders are created manually vs. web checkout
- Whether you operate under GDPR or another consent regime
- Any tracking modules already installed
- Whether you’ve noticed platform conversions running above or below your Odoo order count
That last one is the most diagnostic single question, and this article explains how to check it.
Get a straight answer
If your Odoo conversion data doesn’t match your sales orders, we’ll tell you why, what fixing it involves, and whether it’s worth fixing at your spend level.
Book a scoping conversation →
No obligation. If a module solves your problem, we’ll tell you which one.
Frequently asked questions
How much does Odoo conversion tracking implementation cost?
It depends on your catalogue complexity, existing Odoo customisation, and consent requirements, so we quote fixed price after scoping rather than publish a generic number. What we can tell you: testing and verification is consistently the largest cost driver on projects like this, not the API integrations themselves — conversion tracking fails silently, so verification is most of the real work. If your requirements are simpler, a commercial module in the low hundreds of dollars may cover you, and we’ll say so rather than quote you for a build you don’t need.
How long does it take?
That depends on scope and on your availability for testing, so we’d rather scope it than guess. What we can say about the shape of the work: verification consistently takes longer than the build itself, and it’s the part you shouldn’t compress, because conversion tracking that fails silently looks identical to conversion tracking that works.
Do I need this if I already have a tracking module installed?
Possibly not. Modules handle standard web checkout well. The questions that determine it: do you need immediate transmission rather than batched sending, do you take manual or phone orders, do you need automated retry with alerting, and are your consent requirements standard? If all four are comfortable, keep the module.
Will this work with Odoo Online, or do I need Odoo.sh?
This implementation requires custom Python code — server-side controllers, custom fields on the sales order, scheduled actions — and Odoo Online does not support custom code. Odoo Online is restricted to what Odoo Studio allows: fields, automations, and form adjustments defined in XML, with no ability to install custom backend modules. You’ll need Odoo.sh or a self-hosted instance for a custom build. If you’re on Odoo Online today, migrating to Odoo.sh is usually straightforward, and we can advise on that as part of scoping. A commercial tracking module may be an option on Odoo Online if it’s built to run there — worth confirming with the module vendor before you buy.
Will it survive an Odoo version upgrade?
Custom implementations need review at each major upgrade — the amount of work depends on what changed in the underlying Odoo modules. We document what to check. This is worth weighing against modules, which are released per Odoo version and put you on the vendor’s release schedule instead.
Can you fix an existing implementation rather than rebuilding?
Usually, yes. A partial implementation missing deduplication, consent enforcement, or failure handling is a smaller job than a rebuild, and we’d scope it as one rather than starting over. Send us what you have and we’ll tell you which it is.
