Bohdan's projects

What I did

Opened the audit on two linked stores. Found two GA4 properties on joysportstore (G-V2GVVCLRYE and G-J4JVDP0DFF) with no clarity on which is live — they should be consolidated into one, but I need to inspect both first. Also found Stape server-side code on the site that isn't working, so I asked whether the subscription is still active and whether the client ever actually used it. Requested Shopify Apps + Customer Events access and GA4 admin.

What I did

Ran the audit framework against them. Meta tracking is healthy, but Google Ads conversions are badly inflated — the GTM setup fires a purchase conversion on every page load. I checked the real numbers rather than accepting the summary: 3,248.75 conversions worth $1,795.51 over Jul 6 – Aug 4. Recommended pausing GTM immediately to see what the Google Shopify app records on its own, then rebuilding purchase and secondary ecommerce events in a customer pixel so the two can be compared before committing.

What I did

Checked Merchant Center against the Shopify storefront and confirmed the product IDs match, but there was no purchase event. Went into Google Ads tag activity and filtered purchase hits by pagetype. Checked Meta via MCP and found the last recorded purchase was 17 days old. Determined the Meta setup is the standard app rather than a custom pixel.

The wider finding matters more than this one client: I checked ten Shopify accounts in a row and none had purchase events structured with product IDs, because the Google & YouTube app doesn't send them on purchase. That's shipped app behaviour, not per-client misconfiguration. I then cross-checked with Digestive Warrior — 503 purchases in 30 days, but only 5 hits with IDs matching the feed — and took it to Anna, since it affects dynamic remarketing across the whole book.

Built as a by-product: a reusable Shopify audit framework and a per-point remediation file, which I then reran on Watchmaker and Vesitia to test it on other account types. Traps documented for whoever runs it next: the same gtag stream is not the same emitter, a custom pixel can only add events, the Ads API lowercases product_item_id, and you must check campaign_conversion_goal.biddable rather than trusting the interface.

What I did

Ran the full audit. Found their Google Ads is pointing at pages whose forms aren't tracked at all, while conversion actions sit created but unused in the account — and combined those into a single finding rather than reporting them as separate items. Found the thimRNA LPK pop-up form conversion was triggering on link clicks rather than actual submissions. Went into HubSpot through the browser to check the forms directly, since there's no API or MCP connection, and worked out exactly which HubSpot access level to request to wire a new form from the landing page.

Also analysed the campaign data to decide which product needed a new page: the WGS ad group had been paused at a $229 CPA, which reads as a page failure rather than weak demand, so cfDNA became the target.

Getting in the building: most of the elapsed time here was access, and I ran it directly with the client rather than through a strategist. Their HubSpot sat behind a corporate VPN that kept rejecting the portal address; I worked it through with their marketing manager, joined a call with their IT manager, and got the connection and the disconnect passcode sorted. HubSpot then only gave read-only forms access, so I specified exactly what I needed and why — they made me super admin, which meant giving up a paid seat, so I flagged that I'd tell them the moment it could be reverted.

What I did

CallRail rejected their UK landline as invalid. Contacted support to get UK numbers enabled, which then required a UK Know Your Customer compliance registration. I completed it myself using the client's company details pulled from Metrics/Pipedrive and cross-checked against the UK companies register, rather than pushing the form back to the client and losing a week — then flagged to Anna to confirm that was the right call. Researched whether CallRail runs on Twilio in the UK, and issued the swap-code install instruction for the client's developer.

What I did

They were running four separate GTM containers across three WordPress sites plus Zenoti, each reporting into its own Ads account and GA4. I mapped what every container tracked, then consolidated to one container (GTM-N5TJZJS9), one site, one Ads account as they moved onto a single Next.js build. Reconfigured form tracking for the new form type, rebuilt the container with the container-builder skill, and set up the Zenoti booking tracking. Found form_cf7 wasn't set to primary in our Ads account and fixed it.

When the client insisted only one GTM was live, I proved otherwise: the containers are hardcoded in the app's root layout (app/layout.tsx), which is why they appear on every URL — visible directly in the React server payload in view-source. Sent that to the dev as evidence.

Still open: no backend access, and as of 6 Aug three containers are still on the site. Chased twice; also confirmed no access invites had arrived in the admin inbox.

What I did

Found a HubSpot tracking template set at both account and campaign level. As long as the HubSpot integration is live, changing tracking templates in Google Ads is pointless — HubSpot rewrites them every time. Told the team to stop trying and get the client to either remove the integration or share HubSpot access, and flagged that we'll need GHL access once it's set up to confirm UTMs record correctly.

What I did

The client came to us saying leads weren't syncing into their CRM and they were losing customers over it. I watched the Loom he sent, and put a stop-gap in place the same day — every form submission now emails him directly from our admin address, so no lead is lost while the underlying sync is fixed. Requested admin-level Zoho CRM access to fix the sync itself. He also asked about a new landing page off the back of it.

What I did

Traffic was arriving unattributed. Identified it as paid Microsoft Ads and turned on auto-tagging to fix the attribution, with a tracking template as the fallback if it persists. While in there, updated their Shopify customer pixel code so Enhanced Conversions record correctly.

What I did

CallRail restructure. Two sites shared one number, so reporting was unusable. I laid out two options with the cost implication of each, and built the chosen one: a second CallRail company plus a new website pool, so each site keeps its own number at no extra cost, since CallRail bills per number not per company. Linked Google Ads to both companies and showed the team where per-company reporting lives. Later found the pool numbers were swapping out too quickly and gave two fixes — add numbers at $5 each, or exclude direct and organic traffic from swapping.

The GTM find. Their new WordPress container was never announced to us. I discovered myself that they had created it on the Friday and shared it with our account — it wasn't in the admin inbox and the strategist hadn't passed it on. I picked it up, installed the CallRail code into it, confirmed numbers were swapping, and then went through all their WordPress sites to establish what was actually deployed where.

Conversion architecture. Reviewed the new site — 94 pages, though the sitemap listed only 6 — and proposed splitting conversions by buyer intent rather than one generic form event: RUP Purchase Request, Lab Pest ID Request, and Contact, plus tracking redirects to the Shopify store and email clicks. Reusing their existing GA4 property rather than starting fresh. Built the new container with GA4 and form-submission conversions, set up per-form UPD tags for Enhanced Conversions with trigger sequencing, and tested the RUP form live.

Raised commercially: the Ads account was spending roughly $2,248 per 30 days against zero recorded conversions, and the top form's calculator CTA is a dead button.

The most constrained account I handle — a medical-device advertiser where the wrong parameter is a legal problem, not just a data problem.

Compliance research

Wrote a client-facing research document on what can and cannot legally be tracked, with at least three independent sources per claim and direct citations, built to be handed to their lawyer. Covered HIPAA, BAA and HHS obligations, and included a comparison of compliant booking schedulers — specifically checking, for each one, whether it can still pass call and booking conversions to Google and Meta while in BAA mode, since many disable exactly that. Produced it as a selectable, copyable PDF.

Meta rebuild

Their pixel was sending limb level as an event parameter. I replaced it with numeric conversion values by amputation level so Meta can optimise on lead quality without ever receiving a health attribute, and confirmed the account bills in GBP rather than assuming USD. Consolidated to a single Lead tag instead of the two-tag split I'd first proposed, after pushing back on my own design. Set up Contact for calendar-button clicks, tested live in Meta Test Events, and removed the test code afterwards. Audited every thank-you page and form to establish which were genuinely in use.

Custom audiences & the dead pixel

Built remarketing audiences from scratch, and while doing it found audiences split across two different pixels — one of them effectively dead. Pulled the full list of audiences, which pixel each used, and whether it was active, before building anything new.

The GTM block

Tracking I'd set up wasn't firing on the pop-up-clinic page. GTM simply wasn't loading. I traced it to their WordPress origin filter mangling newlines into a literal _NL_ inside inline scripts, which breaks the GTM snippet. Ruled out the caching plugin and the consent plugin one at a time — including purging Breeze cache and checking the GDPR plugin version — and required source links and exact citations before sending the diagnosis, because a wrong call would have cost another week. Their dev fixed it and tracking now works.

Offline conversion import

Built and shipped the Google Ads offline import for qualified leads, live as a secondary conversion. Flagged that some GCLIDs arrive truncated and therefore can't be matched, with an example.

Iteration: ran across four weeks with repeated rounds against Cai and the client on what was legally acceptable to send. I wrote to the client's team directly, confirmed GTM had been reconfigured to send numeric values only, and got their explicit sign-off on removing the Initiate Checkout event. Their team corrected one of our assumptions about the hero-arm form being static — it is dynamic and does collect limb data — which I took on board and rebuilt the value mapping around.

What I did

Tested the tracking end to end in their GHL, then decided against a staged proof when two real conversions had already come through — no point manufacturing a test to prove something the live data already showed.

Audited the calculator itself and found several distinct problems. The calculator still pushes the site-wide lead_form_submit alongside its own event, so one lead is counted two or three times in GA4. calculator_gate_completed carries no customer data, leaving Enhanced Conversions nothing to work with. A third step — booking a call — isn't tracked at all, because it redirects to a confirmation page with no GTM on it. And calculator_gate_step1 doesn't exist in GA4 at all, because GTM sends it under the old name calculator_tier1_completed; I asked for permission to rename rather than doing it silently, noting it was safe because the event has only a handful of submissions.

On the Ads side I changed the trigger so the Calculator tier-2 form conversion started collecting. Also caught that prospects could still see calculator results without submitting anything, and that the fields were structurally wrong — reported as a probable bug rather than assuming intent. Wrote the developer spec listing exactly which events to keep, remove and rename and what data each needs, scoped so nothing has to change in GTM on their side.

Attribution design. Separately worked out how to carry the email from step 1 to step 2 through localStorage so they can use one webhook instead of two, and wrote up first- and last-touch attribution in GHL — storing the first gclid on the guide-subdomain submission so a lead that later converts on the calculator can still be traced back to the guide campaign.

What I did

A platform I hadn't set up before, so I said so internally rather than bluffing, then did the research properly — articles, forums and the Adobe Commerce marketplace — and compared the realistic integration routes specifically on whether each actually supports purchase tracking. Delivered a ranked recommendation with Meta's own free extension as the starting point.

What I did

Built container GTM-TSBFB483 covering both the main site and the new landing page, while leaving their two legacy containers intact so nothing broke mid-migration. Discovered the GTM code was present on the main site but not actually executing because of how it had been added, and produced a copy-paste install for Marketing 360 formatted to be usable by a non-technical person. New conversion actions for both the main site and the LP, both primary, with separate labels so LP leads stay distinguishable.

Marketing 360 CRM. Wired submissions into contacts, worked through the API to get the source IDs right — including tracking down a stale source ID left behind after a deletion — and was straight with the team that contacts rather than leads is genuinely the most the CRM allows, since its lead flow only accepts their own native forms. Ran a real test submission with tagged UTMs to confirm gclid arrives, and confirmed gbraid and wbraid record too.

CallRail. A long-running mess I chased to the end: the client believed her account was renewed, but CallRail support confirmed it was a disabled trial. I got that in writing, relayed it, then when the account came back found CallRail had deleted all previous numbers and had to create a new website pool. When they proposed another number at $3/month, I proposed excluding direct and organic traffic from swapping instead, so the client pays nothing extra.

What I did

GA4 was recording no purchases at all. Worked through the BigCommerce Script Manager setup, taking care not to disturb the Twitter and affiliate conversion tracking sharing the same block, and shipped a fix into the affiliate section with Enhanced Conversions corrected for Ads.

Then the harder half: I couldn't run a test purchase, so I had to verify against real orders as they came in over several days. That surfaced two further problems the first fix didn't cover. The recorded value was the pre-discount subtotal, so I traced how BigCommerce exposes order amount and offered the client the choice of pre- or post-discount to stay consistent with Ads. And purchases were still intermittently missing — which turned out to be the cookie-consent banner blocking Analytics until a shopper clicks Accept, which most never do. I checked current US privacy law before recommending they switch it off, and kept the recommendation short and free of unproven claims.

Iteration: took most of a week and several dead ends. I said so to the strategist rather than presenting it as clean.

What I did

Confirmed GTM was present in the theme so the CallRail swap would work, got numbers swapping, and added the GA4 integration. Found the Contact and About pages use a different number that isn't a swap target, and — before recommending anything — established exactly what adding it would cost and whether it would swap to one tracking number or two, because the client would be paying for it.

What I did

Set up the access request to migrate their offline conversion import from Zapier onto the newer, more reliable engine — recorded a Loom walking the client through granting Shopify app developer permissions rather than sending written steps. Chased twice.

The largest project of the period: rebuilding an entire ecommerce measurement stack so it survives a platform migration without losing a day of conversion data.

Ecommerce tracking

Built Purchase and Add to Cart into a Shopify customer pixel with conversion labels matched to the old Ecwid site so historical reporting stays comparable, and verified the value field against what the old site recorded rather than assuming. Added GA4 into the pixel with a switchable test mode so it couldn't pollute live data, anchored the GA4 client ID to Shopify's Web Pixels API client ID, and excluded my own IP as internal traffic.

The product ID problem

The hardest single problem I solved this period. Dynamic remarketing and purchase reporting both need product IDs that match Merchant Center — but Merchant Center holds legacy Ecwid IDs while the Shopify storefront exposes Shopify IDs. I spent days on it: checked the theme liquid, inspected the Add to Cart button markup, read the network requests, and found the Ecwid IDs sitting in Shopify product metafields — by browsing Shopify myself rather than waiting on a developer. I then established exactly where the developer must surface them, and wrote that as a dev-facing instruction including how they can verify it from their side. I demanded exact citations for the claims in that instruction and rejected two rounds of sources that didn't actually support the point.

Along the way I found the reason product view and add-to-cart events appeared to fire nothing: the store wasn't publicly live yet. I checked that with a senior tracking specialist, then summarised her call for the client document.

GTM in theme, forms and chat

Worked out where GTM belongs in the theme liquid and got it installed and confirmed live. Mapped every form on the site — Contact, Trade-in/Sell, Request More Information, Notify Me When Available, Affiliate, Careers, Newsletter, Credit — and gave a recommendation per form on whether to track it in Ads, GA4, or not at all, rather than tracking everything by default. Set up Enhanced Conversions per form and tested submissions live in GTM preview, catching that the UPD tag was firing after the conversion tag and correcting the sequencing. Investigated LiveChat and established its native GA4 app already covers chat events, so no duplicate GTM setup was needed.

Go-live

Wrote the cutover procedure — connect pixels and pause GTM at the same moment — so the migration wouldn't double-count, and gave the dev the exact clicks. Verified all tracking after they went live, then investigated a GA4 transaction arriving from something other than our pixel.

Iteration: the client document went through six versions, with formatting and wording reworked repeatedly for a non-technical reader, and the GTM container import rebuilt after I found it contained duplicated and auto-paused tags.

Working with their web agency: I corresponded directly with the client's developers throughout — confirming Ecwid IDs were available, flagging clearly that form submission tracking was not ready while ecommerce was, and putting specific questions to them about how each form behaves rather than guessing. On launch day, 2 August, I monitored delivery across the switch to catch anything breaking in the first hours.

What I did

Checked whether purchases can happen by phone or email after a form submission and whether those get logged in Shopify as draft orders — because if they do and we don't capture them, the import silently under-reports revenue.

Our own funnel went live while I was mid-setup, so this ran as live debugging against real money and real orders.

What I did

Ran a real end-to-end test order through the live funnel with a 100% discount code rather than trusting a test event. Then worked through why purchases weren't appearing in the campaign: I audited every real order against the Cloudflare Worker logs and Meta, established 15 real purchases with 13 attributed, and traced each miss individually — the first had no fbclid or UTMs at all (organic, forwarded link, or private browsing), and I was explicit that I couldn't fully verify the other because the log data had expired, rather than inventing an explanation.

Pushed hard on Meta's actual limits around custom events with dynamic values, refused several answers that didn't match what the interface showed me, and made the call to revert to the standard Meta Purchase event so Meta can optimise properly — reviewed with Anna first, then duplicated the campaign because the optimisation event can't be changed on a published one. Extended the Worker's logging window so this is diagnosable next time. Kept the Worker running in parallel as a cross-check on ThriveCart's own attribution.

Also fixed the Meta domain configuration, verified the training subdomain, checked the Meta Gateway test-period expiry risk and confirmed we were covered by Stape's tokens, and assessed whether the fbclid survives the advertorial hop in in-app browsers before a listicle campaign launched — including asking how common the failure case actually is before spending time on it.

What I did

Got Own CDN live — walked through the Cloudflare DNS change to proxy the Stape subdomain and set SSL mode correctly, so our tags load first-party and survive tracking restrictions. Then prepared the Custom Loader rollout across every GMA page, which reloads the container if a blocker stops it.

The judgement call worth noting: Enhanced Ad Blocker Protection recovers more data but requires every platform to be updated simultaneously. Rather than push for the better option and risk a broken rollout across pages owned by different people, I supplied a version that can be deployed gradually, and set out clearly what would need to change for the stronger option. Wrote the instructions for whoever holds each platform, and chased repo access for the one funnel I couldn't reach.

What I did

Produced a Loom and a PDF for the client walking through the proposed offline attribution approach, so the concept could be sold without a technical call.

What I did

Chased the outstanding Popmenu problem, where the GTM snippet sits in the page payload but never executes, so nothing can be collected. Diagnosis was already delivered; this was keeping it from going quiet.

What I did

Ran the build. Product chosen from campaign data rather than preference. Headline built on their verified 9x yield at 1ng figure and their real BSI certification. When asked to confirm a claim wasn't already used elsewhere, I checked every landing page on the site and listed them all rather than answering from a spot check. Confirmed no testimonials exist anywhere for this company and used none.

Set up the client Cloudflare account and project, diagnosed the subdomain SSL error, and wrote a short DNS change request for their IT team — cut down twice because my first versions were too long for the audience. Checked their registrar and DNS are both on GoDaddy before writing it.

What I did

The broadest single client relationship in this period — page, tracking, backend and enablement. Tweaked tracking on the existing pages, built a new landing page and a new PDF brochure, and set up the tracking for the new page.

Beyond the build, I ran several calls with the client and her assistant: taught them how to use Claude to produce their own landing pages, using the page we'd built as the worked example, and walked them through creating and managing GHL webhooks themselves.

I am her direct contact. She emails me rather than a strategist, and I handle it end to end. When she questioned her conversion numbers, I gave a direct answer — yes, one person can be counted twice, once per goal, because a form fill and a booking are separate goals — with the actual figure (6 bookings from Ads in 90 days, so the overlap is negligible) and the exact steps to verify any individual case in GHL. Recommended setting conversion counting to One on the lead-form actions.

Saved her money unprompted. She asked whether she still needed CallRail after being charged again. I pulled her actual usage — only 10 new-customer calls in 30 days — told her plainly she was overpaying for what she was getting, and cancelled it for her, confirming it stays active for the month she'd already paid for. Also chased down a campaign she thought had disappeared from her Google Ads account.

What I did

Added an outbound route from the landing page to their main site — the logo top-left is now clickable and opens the main website in a new tab — and, rather than leaving that traffic invisible, created a new Google Ads conversion for it so we can see how many LP visitors move through to the main site.

Then scoped offline conversion import for their in-store sales: specified that we pull the GCLID (or GBRAID/WBRAID) from CallRail and need name, phone, conversion value and date from the client. Flagged the real limitation honestly — if someone calls from one number but gives a different one when buying in store, that sale can't be matched unless their system links the two.

What I did

go.vantageelitefitness.com  ·  mobile preview at vantage-elite-lp.pages.dev/mobile-preview

Built the page, the Apps Script backend into a shared sheet, and the thank-you page. Added a per-browser 15-minute resubmit lock after finding I could submit five times in a row — that's both spam protection and conversion-inflation protection. Fixed the phone field to reject letters as typed and corrected its formatting. Ran the page through a mobile pass and fixed the header phone number and footer service-area ordering.

Images. Migrated everything to the client's Cloudflare so nothing depended on their WordPress, then when images still vanished for some viewers, diagnosed it as browser cache holding the old WordPress URLs and re-uploaded every image under new filenames so even cached pages recover.

The calendar. Embedded Cal.com on the thank-you page and rebuilt the layout to match their main site — removed the stray Cal.com branding and link, dropped an empty photo block, tightened the spacing, and got the calendar visible without scrolling. Caught that booking redirected users off to the main site and reverted to the live version until it was fixed properly.

DNS. The client had moved DNS management from Squarespace to Hostinger mid-build. I established where DNS actually lived, wrote step-by-step instructions for the client, and rewrote them repeatedly — including redoing the PDF after checking how it actually looked — because the first versions weren't clear enough for a non-technical reader. Then I ran it directly by email with Zach and his assistant: when they couldn't find the option my document described, I read their screenshot, worked out the actual path on their account (Websites → the domain → Advanced → DNS Zone Editor), and walked them to it until the record was added and I could confirm it live on the Cloudflare side.

Tracking. They had no GTM at all and a hardcoded gtag. Built a complete container from scratch, passing all 28 checks on our validator, using the four-component Enhanced Conversions pattern with the UPD tag firing before the conversion tag. Installed it on WordPress via GTM4WP, then tore out the old tracking cleanly — disconnected Google Ads and GA4 from Site Kit to stop double counting, found and removed the HFCM snippets, and worked through LiteSpeed's JS deferral and cache settings so nothing was being suppressed. Added a tracking template in Ads. Tested in GTM preview before publishing, caught the UPD tag not firing on the calendar submission, and fixed it. Pushed back on a page-view-based conversion in my own setup, since a reload would have counted again.

The Cal.com trigger. My booking listener pushes cal_booking_success, but the same event fires on both the main site and the Go subdomain, so a naive trigger would double-count. Split it by hostname to keep them separate and future-proof against someone changing the main site later.

Caught in testing: the main-site contact form showed as inactive since 18 July, and GTM debug wouldn't attach on the thank-you page. Both found by me while testing rather than reported by anyone else, and both fixed.

Iteration: a continuous loop with Valerie and Andrew over layout — how many results fit on one line in Kevin's story, how the certification badges should wrap — plus repointing submission emails to the client once testing finished.

What I did

Took the page from built to live on the client's own infrastructure. Recorded a Loom showing their developer how to create a Cloudflare API token — and made a point of explaining he can revoke it the moment the page is live, plus offered the alternative route where he imports the repo himself and we never hold a token at all. Diagnosed the CNAME pointing at a stale Workers hostname and gave the exact value to change it to.

Set up the conversion for the guide page as secondary, and raised the question of whether it should carry a value, noting the contact form conversion is set at $50, rather than deciding unilaterally.

What I did

Took the page live and wired the backend. Form submissions flow into Marketing 360 contacts, the client gets an email for every submission, and everything also lands in our sheet as backup. Fixed a multi-step form bug where focusing the zip field pushed the last field onto the next page, and reworked a custom dropdown twice before concluding the native browser control was genuinely better and reverting — rather than defending my own work.

Ran a full PageSpeed and Lighthouse pass and applied the fixes. Merged Valerie's late change (adding Tim's photo) and verified it hadn't collided with mine before pushing.

What I did

A Zap failing its test with "cannot filter by _zap_static_hook_code" looked like dead authentication. It isn't — the connection is fine and other triggers work; it's a bug in ChargeOver's own app affecting the New Customer trigger, reproducible even in a clean Zap with no filters or steps. Gave the decision path so nobody rebuilds a working Zap for no reason.

What I did

Keeping the setup that runs everything else working. Connected the Meta MCP so I can query Meta directly instead of clicking through Events Manager. Audited what was running on the machine and stripped out unused integrations that were slowing it down, including removing Perplexity across all commands and skills. Recovered session context after crashes and restarts. Changed the build skill so it stops injecting its prompt into every unrelated request. Cleared a client VPN that had locked the machine without a passcode.

What I did

Wrote the standing documentation for landing-page deployment so it isn't rebuilt from memory each time: a screenshot-by-screenshot guide to creating a Cloudflare account token, and the full project creation walkthrough for the case where a client shares or creates their Cloudflare account live on a call. Shared with Anna for the team.

Also set up a booking link so Valerie can route tracking, CRM integration and deployment requests to whoever has capacity, rather than every request landing on one person.

What I did

Every Monday: check Pipedrive for duplicate records and fill out the lead dashboard on Netlify. Roughly an hour a week across the period.