Dog Academy: what the Meta data shows, and what's wrong

These are screenshots of Dog Academy's pixel in Meta Events Manager (pixel 481578137302100), taken Oct 23, 2026. The window is the last 7 days, Oct 16–22. The server tracking (CAPI) was switched on Monday, Oct 19.

The short version. CAPI is on, and it has been sending data to Meta since Monday, Oct 19. That's why we can already see data. The data quality isn't good enough yet to tell Meta "find me people who buy." Four things are wrong:

Sales are double-reported. Each Purchase comes in from both the website and the server, and Meta can't tell they're the same sale.
Sale amounts are wrong or missing. Only 44% of Purchases send a valid amount, and every website Purchase sends the exact same price.
13 other websites are sending data into Dog Academy's pixel. That includes test sites and some random sites we don't recognize.
We don't know which event is the real Trained for Life sale. There were 837 "OrderCreated" events but only 124 "Purchase" events this week. We need the developer to tell us what each one means.

Screen 1: The event list (everything the pixel received this week)

Events Manager event list, last 7 days — Events Manager → Dog Academy's Pixel → Overview, last 7 days.
Open in Facebook: Overview ↗ Set the date (top right) to “Last 7 days.”

Date range: Oct 16–22. Meta shows totals for whatever dates are picked here. CAPI only started on the 19th, so the server events in this list really cover about 3½ days, not 7.

PitchedCall and OrderCreated say "Conversions API." That means they come from Dog Academy's server, not the website. These are the new events, and they only exist because CAPI was switched on. This is the proof it's live.

Purchase has "2 warnings." Both are about the sale amount (see Screen 4).

124 Purchases vs 837 OrderCreated. That's a big gap. See Problem 4.

What each row is, in plain English

Event	From	This week	What it means
PageView	Website	113.2K	Someone loaded a page.
Lead	Both	2.5K	Someone submitted a form.
Book Training Lead	Website	2.4K	A custom event Dog Academy made, probably the booking form.
PitchedCall	Server new	1.3K	A rep pitched on a call. Started Oct 19.
OrderCreated	Server new	837	An order was created in their system. Started Oct 19. unclear
Purchase	Both	124	A sale. This is the event we want Meta to optimize to. broken
Initiate checkout / Add to cart	Website	60 / 60	Someone started an online checkout. This is probably the courses checkout, not TFL.
__missing_event	Website	5	Events sent with no name. It's minor, and Meta says it's no longer happening.

The yellow triangles next to Lead and Book Training Lead only say "Errors found, see Diagnostics." Diagnostics doesn't list a separate Lead error, so those triangles are pointing at the same problems below.

Screen 2: Purchase. Proof CAPI started on the 19th, and Problem 1

Purchase event chart, browser vs server — Dark blue = website (browser pixel) Teal = server (CAPI)
Open in Facebook: Overview ↗ Set “Last 7 days,” then click the Purchase row.

The teal line doesn't exist until Oct 19. Before Monday, only the website reported Purchases (the dark blue line). On Monday around midday, the server started sending them too. This is the clearest proof of when CAPI went on.

"Improve deduplication." Meta is telling us it can't match the website Purchases with the server Purchases.

Purchases, Oct 16–22	Count
From the website (dark blue)	35
From the server (teal), Oct 19 onward only	89
Total Meta shows	124

Where you can see the double-counting: Purchase → Event deduplication

Purchase event deduplication keys — Events Manager → Purchase → View details → Event deduplication.
Open in Facebook: Purchase deduplication ↗ This link goes straight to this screen.

Event deduplication is the page Meta uses to show whether the website copy and the server copy of each sale are being matched up.

Event ID row. The server sends the order ID on 100% of its Purchases (17). The website sends it on only 37.5%. Without an ID on both copies, Meta can't pair them, so it treats them as two separate sales.

Total event coverage rate: 25.76%. Only about 1 in 4 sales gets matched. Meta's own note under the table says to get this to at least 75%.

Above the table, Meta also shows its own warning: "Improve event ID coverage by fixing deduplication key issues… Send a message to your developer." It even has an "Email instructions" button for the dev.

Problem 1: what's wrong When the same sale is reported by both the website and the server, both copies need to carry the same ID number (an "event ID"). That's how Meta knows they're one sale and not two. Right now they don't match, so Meta adds them together. That means one of two things:

the same sale is getting counted twice, or
the website and the server are reporting different things under the same name, "Purchase."

We can't tell which from here. Either way, Meta's sale count is wrong.

Why it mattersWhen we tell Meta "find people who buy," it learns from this count. If the count is inflated or mixes two different things, Meta goes after the wrong people.

The fix (developer)Send the same event ID with both copies of a sale, built from the order number (for example da:purchase:ORDER123). Once that's done, the browser and server copies merge into one.

The website and the server are both telling Meta about each sale, but they're not using the same order number. So Meta can't tell it's the same sale and probably counts it twice. The dev just needs to send the same order ID on both.

Screen 3: OrderCreated. Also starts Oct 19

OrderCreated event chart starting Oct 19 — OrderCreated is server-only. The chart begins on Oct 19 because the event didn't exist before then.
Open in Facebook: Overview ↗ Set “Last 7 days,” then click the OrderCreated row.

The first data point is Oct 19. PitchedCall looks the same. Both are brand-new events that only exist because of CAPI.

Problem 4: what's wrong 837 OrderCreated events vs 124 Purchases in the same week. Trained for Life is about $1,200, and 837 paid TFL sales a week isn't realistic. So OrderCreated is probably something earlier in the process, like an order drafted on a call or a pay link sent, and not money collected. But we're guessing. We also don't know if the 124 Purchases are TFL sales or cheaper course sales. The 60 add-to-carts and 60 checkouts on the website suggest at least the website Purchases are online course checkouts.

Why it mattersIf we optimize to the wrong event, Meta finds people who buy a cheap course, or people who just get an order drafted, instead of people who pay for TFL.

The fix (ask the developer)What exactly fires OrderCreated? What fires Purchase? Does Purchase include course sales, or only TFL? The ideal is one event that fires only when TFL money is actually collected, with the real amount.

We're seeing about 840 "orders created" this week but only 124 "purchases." What does each one actually mean? Which one is a paid Trained for Life sale?

Screen 4: Diagnostics. Meta's own list of errors

Events Manager Diagnostics, 3 active errors — Events Manager → Diagnostics. These are written by Meta, not by us.
Open in Facebook: Diagnostics ↗

"Only 44% of your Purchase events are sending a valid price and 3-letter currency code." More than half the Purchases arrive with no amount, a broken amount, or no "USD." Meta wants at least 90%.

"All of your web Purchase events are sending the same price." Every website Purchase reports the identical dollar amount, no matter what was actually bought. That means the amount is hard-coded on the thank-you page rather than pulled from the real order. Meta first flagged this Oct 13, before CAPI, so it's the old website pixel.

"Confirm domains that belong to you." Other websites are sending data into this pixel. See Screen 5.

Problem 2: why the amount mattersTo aim for high-value buyers ($1,200 TFL, not a cheap course), Meta has to see the real amount of each sale. If every sale says the same number, or no number at all, Meta can't tell a big sale from a small one.

The fix (developer)Send the real amount charged and currency: "USD" on every Purchase, from both the website and the server.

More than half the sales show up in Meta with no dollar amount, and the website ones all show the same price no matter what was bought. We need the real amount on every sale.

Screen 5: The 13 other websites using Dog Academy's pixel

13 new domains sending data — From the "Confirm domains" error, after clicking "See All 13."
Open in Facebook: Diagnostics ↗ Click “See All 13” under “Confirm domains.”

Website	What it probably is	Keep?
stage.dogacademy.org, mobile.dogacademy.org	Dog Academy's own staging and mobile copies	dev decides
dogacademy.test, dog-academy.test	A developer's laptop copy of the site	block
96e491101426.ngrok.app, 3d2162bc32c3.ngrok.app	Temporary test links a developer opens to their laptop	block
13.59.163.106, 13.58.149.61	Raw server addresses, likely test or staging servers	block
www-dogacademy-org.translate.goog	Real visitors reading the site through Google Translate	keep
unbeatablepicks.com, flashdealwizard.com, tatrck.com, lkht.top	Unknown sites with no connection to Dog Academy. Usually this is someone who copied a page with the pixel on it, or a tracking or redirect service.	block

Problem 3: why it mattersAnything these sites send counts as Dog Academy data. That includes test purchases a developer makes while building, and junk from sites we don't recognize. Meta learns from all of it, and fake test sales make the numbers look better than they are.

The fix (whoever runs Dog Academy's Meta)Events Manager → Settings → Traffic permissions → allow only dogacademy.org (and the Google Translate copy). Everything else gets blocked. It takes about 5 minutes, and we can do it if they want. We haven't touched it.

There are 13 other websites sending data into our pixel. Some are the dev's test sites and some are random sites we don't know. We should lock the pixel to dogacademy.org so test orders and junk stop counting.

Screen 6: The "2 warnings" on Purchase, close up

Purchase warnings popup — Hovering the orange "2 warnings" badge on the Purchase row.
Open in Facebook: Overview ↗ Hover the orange “2 warnings” on the Purchase row.

These are the same two amount problems from Screen 4, shown right on the Purchase row: 44% valid amounts, and the same price on every website Purchase. There's nothing new here. This screen just shows Meta flags it in two places.

What's working

CAPI is live. The server has been sending PitchedCall, OrderCreated, Purchase and Lead since Mon Oct 19, and new ones keep arriving all day.
Matching is strong. Purchase match quality is 8.0/10, and 100% of website Purchases carry the buyer's hashed email, phone, name, city and ZIP. That's what lets Meta tie a sale back to the person who saw the ad.
Server coverage is fine now. The server sent 89 Purchases this week vs 35 from the website.

A correction to what we said before. We earlier said "only 12% of Purchases come from the server." That number was measured over Sep 23 – Oct 20, which is mostly before CAPI existed, so it was misleading. Since the 19th, the server sends most of the Purchases. That's off the list. The four problems above still stand.

The ask, in one message

So CAPI is working, and data has been flowing since Monday. Four things before we can optimize to sales: (1) send the same order ID from the website and the server so sales aren't counted twice, (2) send the real dollar amount and USD on every Purchase, (3) lock the pixel to dogacademy.org, because 13 other sites including test sites are sending into it, and (4) tell us what OrderCreated vs Purchase actually mean, and which one is a paid Trained for Life sale.

Source: Meta Events Manager, Dog Academy business, pixel 481578137302100, read Oct 23, 2026. The Facebook links open for anyone with access to the Dog Academy business (read-only, nothing changed). The Purchase website/server split is from Meta's own chart data for Oct 16–22.