Dog Academy × Meta: tracking the leads that turn into sales

1. Summary

We want Meta to find people who book a free consultation and go on to buy Trained for Life, not people who just fill in a form. Meta can only do that if it can see what happens after someone clicks an ad. Right now it can't.

Where tracking stands today

We submitted one labelled test lead through the quiz on 28 September and watched every request. Here's what we found:

• The quiz sends Meta nothing. No Meta event fired at any step our test lead reached, through the email step. The phone check stopped it before the final submit. Google Analytics gets "Step 1, Step 2…", but Meta only gets page views and automatic button clicks.
• There is no server-side tracking (Conversions API). Everything depends on the browser pixel. Ad blockers, iPhones and cookie limits drop a share of those events.
• The pixel is missing from some pages: the private, group and online program pages, and the Heyflow city funnels on training.dogacademy.org. The Facebook click ID is only kept if the visitor lands straight on the booking form.
• Meta is matching the wrong name. Its automatic matching reads your dog's-name field as the owner's last name, which lowers how well Meta can match leads to real people.
• Sales happen on the phone, days after the click, and nothing tells Meta about them.

What we're proposing

1. Fix the pixel. Put it on every page that matters, take it off the service-dog and psychiatric pages, and stop the name mix-up.
2. Add the Conversions API. Your server sends the same events as the browser, with a shared ID so nothing counts twice.
3. Track three website events properly: Lead (quiz submitted), Schedule (free consultation booked) and Purchase (Trained for Life paid on your site).
4. Take payment on your site. Reps close on the call and send a pay link, so the customer pays on dogacademy.org. That is what lets Meta optimize to buyers.
5. Feed the later stages from your own systems: consultation completed, purchase and, optionally, "sale kept" after the refund window. This goes through a small secure endpoint, a daily file or Zapier.
6. Test everything with Meta's test tools and one real end-to-end test lead. Then we launch ads optimized to Purchase, the sale.

Time: the programming is about one developer day, plus the pay link if you don't already have an online checkout. Launch-ready in about 3–4 days, because Meta needs 48 hours of real traffic before it can score match quality. Nothing in this plan changes what your leads see, and none of the tracking code is allowed to break the quiz or the booking page.

The goal: leads that buy

Meta's delivery system learns from whatever event we tell it to chase. If we tell it "form filled", it finds form-fillers: people who get curious, never book and never answer the phone. We have $10k to find winners, so every learning event has to point at buyers.

Why the sale has to be paid on your site

• We optimize to the sale. The ads are told to find people who buy Trained for Life, not people who fill in the quiz or book a call.
• Meta can only optimize to what happens on your website, within 7 days of the ad click. A card taken over the phone and logged in your CRM can be reported to Meta, but it can't train the ads.
• So the rep closes on the call and sends a pay link. The customer pays on dogacademy.org. Your site fires Purchase from the browser and the server, and that is the event the campaign optimizes to.
• Expect "learning limited" at first. Meta learns fastest at about 50 sales a week per ad set, and a test budget produces far fewer. It still steers toward buyers, just more slowly.
• Sales that close after 7 days still come in through the CRM feed, so we see the real cost per sale for every ad.
• If your ad account offers Meta's "qualified leads" goal for website forms, it can learn from CRM sales up to 28 days after the lead. We check that in Ads Manager once we have access.

Why we still send the other stages

• Truth per ad. We store the campaign, ad set and ad ID on every lead. Your CRM can then answer "what did this ad cost per completed consultation and per sale?", which is the number that actually matters.
• Room to grow later. Buyer data could seed buyer audiences down the line. For launch, targeting stays broad, with no custom audiences.
• Reporting inside Meta. Ads Manager can show the consultations and sales it manages to match to an ad next to spend, as report columns. Your CRM stays the source of truth.

Why both the browser and the server

• The browser pixel alone misses events. Ad blockers, Safari and in-app browsers all drop some.
• The server copy fills the gaps and carries better matching data: hashed email and phone, plus the click ID.
• Both copies carry the same event ID, so Meta keeps one and discards the duplicate.

Why we're strict about accuracy and privacy

• Each event says honestly where it happened: website, phone call or other. Meta's terms require it, and mislabelling phone sales as website events can get a dataset restricted.
• No health or service-dog information goes to Meta, ever. That includes the psychiatric and service-dog pages, veteran status, quiz notes and call notes. Meta can restrict a dataset that receives health data, and a restriction would break the sales optimization this whole plan depends on.
• Contact details are hashed before they leave your server. Meta receives scrambled codes, not raw emails or phone numbers. The access token lives in a secret store, never in code or email.
• We never send "negative" events: no refunds, no-shows or lost deals.

3. What Meta will see at each stage

How Meta ties each event to a person. Website events carry the ad click cookies (_fbc, _fbp), IP address, browser and hashed contact details. Stages from your CRM reuse the identity your site saved on that lead, plus your lead ID as external_id.

How Meta avoids counting twice. When the browser and server copies share the event name and ID, Meta keeps one. It deduplicates within 48 hours.

The contract value is only used inside Meta's reporting. Ads never show the price.

4. Technical: what gets installed where for your developer

This is the short version. The complete build spec, with the code, database schema, event contract and test plan, is here: Dog Academy Conversions API build instructions. We based it on what we saw on the live site: a Laravel app with Livewire, behind an AWS load balancer, with DNS on Cloudflare. Your developer should correct anything we got wrong.

5. How we'll know it's right before any money is spent

Ads launch only when every box below is ticked. Your developer runs the build; we check the numbers in Events Manager with you.

• Each event shows up. On the staging dataset, every event in section 3 appears in Meta's Test Events tool, from the browser and from the server where both send it.
• Nothing counts twice. Browser and server copies of Lead, Schedule and Purchase merge into one, for at least 90% of pairs.
• Clean payloads. Nothing from section 4G. Contact details only as hashes. Event IDs follow the pattern in section 3.
• The ad click is kept. _fbc is present on at least 90% of leads that came from a Meta ad.
• The CRM feed works. A consultation marked held and a sale entered in your CRM reach Meta through the webhook within an hour.
• One full test lead. With a phone number you control, because the quiz rejects fictional numbers: quiz, booking, held, then paid through the pay link (processor test mode, or a small charge you refund). Every step is visible end to end. Your sales team should leave it alone.
• Match quality after 48 hours live. Event Match Quality of at least 7.5 out of 10 for Lead, Schedule and Purchase, aiming for 8. Server coverage of at least 75%, aiming for 90%. Events arrive within an hour.
• The account is ready. Access works, the dataset has a single server sender, the domain is verified, the pixel is on every page it should be and off the service-dog pages, the privacy checks pass, and Ads Manager offers Purchase under the Sales objective.

After launch: a day-7 reconciliation of your CRM counts against what Meta received, then weekly, before any budget increase. We check all of this on our side. We don't write anything into your systems.

6. What we need from you

• Meta access: Brett as admin on the Business that owns pixel 481578137302100, the Page and the ad account.
• A developer who can start this week, with this page and the full build spec.
• Your systems: which CRM, dialer and billing tools you use, and whether each can send a webhook. If not, we use the daily file or Zapier.
• Stage definitions:
  • what counts as a "completed consultation" (disposition code, minimum talk time, phone or video);
  • what counts as a sale (first payment or signed contract, and which amount);
  • where refunds are recorded.
• Who books and who runs the free call: mostly the lead on the website, or an agent? A sales advisor or a trainer? The homepage promises a call from a "dog training concierge", while the quiz promises a "free 30-minute virtual meet & greet". Ads should promise the one that is true.
• The pay link (required): your reps send a pay link on the call, so the customer pays on dogacademy.org. Which checkout and processor should it use?
• Numbers:
  • lead → booked → completed → sold rates, with monthly counts for the last 3 months (including refunds);
  • how long each step takes after the lead, especially the share that happens within 7 days;
  • margin per sale;
  • the ZIP codes your trainers cover.
• Testing:
  • a Dog Academy phone number we can use for the one test lead;
  • please delete the partial test lead we left on 28 September: "TEST AdMaker Lead", admaker-da-test-kd492w@mailinator.com, plus any copies in Klaviyo, Amplitude or the CRM.
• Your counsel's choice on the opt-out mode (section 4G).

7. Timeline and who does what

Who does what: your developer builds; your admin handles Meta Business settings, the token and the domain; you and your ops team define the stages and connect the feeds. We handle the checks, the ads and the reporting.

8. Glossary