Shinjiru Wellness — Reseller-Recruitment Funnel on Cloudflare Pages

Context

The four Shinjiru product pages sell supplements to customers. This page does a different job: it recruits the people who will resell them. "Become a Shinjiru reseller — earn 30–41% margin," take a ₱1,000 commitment, capture who applied, and route them into Messenger for onboarding.

That different job called for a different build. The product pages live on WebCake and route orders through Botcake/Pancake. The reseller funnel is a single self-contained HTML page on Cloudflare Pages, with its own Google Apps Script backend — no page builder, no POS dependency, free hosting on a custom subdomain (resellers.shinjiruwellness.ph). It's the same order-ops DNA as the product pages, rebuilt as an acquisition engine I own end to end.

The Challenge

Recruit-and-onboard in one page, without a real checkout or customer accounts.

• Sell the margin, then ask for commitment. A reseller prospect needs to believe the numbers before they put money down. The page has to make the 30–41% margin concrete, then convert that belief into a ₱1,000 deposit — in a market that pays cash-on-delivery and lives in Facebook Messenger, not hosted checkout.
• Capture identity without an account system. PH recruitment runs through Messenger, which strips every URL parameter except ref. So the page itself has to be the system of record: who applied, what they ordered, whether they came back, and whether the same person applied twice under a different name.
• Attribute every step to the ad spend. Meta ads optimize against events, not page views. The funnel needed a real event ladder — and resilience against iOS/ad-blocker loss — wired in from launch, not bolted on.
• Fast on a throttled mobile pipe. A recruitment page with a hero video and a dozen product posters can't punish a prospect on cellular. Performance and SEO were build requirements, not an afterthought.

Approach

1. One page, globals-thin. The entire funnel is a single index.html with its asset tree — design tokens, behavior, and the capture modal all in one self-contained file that uploads to Cloudflare Pages verbatim. Nothing custom is hosted or maintained beyond the page and one Apps Script.
2. A three-stage apply modal. Add a package → the checkout modal opens at Stage 1 (review & apply): selected package, live "you earn vs. your cost" math, optional margin-boosting upsells, and the applicant form. Stage 2 takes the ₱1,000 deposit — native receipt upload (camera or gallery) or "I'll send it on Messenger instead." Stage 3 hands off to Messenger. Each stage maps to a funnel event.
3. The page is the CRM. Every Stage-1 submit writes a Lead; every Stage-2 commitment writes an Applicant; both resolve to a single Customer identity. The Apps Script backend is the single source of truth.
4. Attribution as a single switch. The whole Meta Pixel funnel is guarded behind one PIXEL_ID variable — flip it on and PageView → AddToCart → InitiateCheckout → Lead → Purchase all fire, with hashed advanced matching and per-order event IDs for dedup.
5. Performance budgeted, then measured. Real PageSpeed Insights data drove the optimization pass rather than guesswork.

What I Built

The recruitment funnel. A single Cloudflare Pages site with the full conversion stack:

• Hero with a muted looping background video and the margin pitch up top
• ROI calculator — tap any Partner Combo or Refill pack to see cost / revenue at SRP / profit / margin %, numbers pulled straight from the price list
• Three-stage apply modal — review & apply → ₱1,000 deposit with receipt upload → Messenger handoff, with a header trust band (BPI · BDO · GCash + FDA · DTI · SEC · BIR seals)
• Collapsible margin upsells — add Partner Combos (30–41%) or refill packs (30–40%) inside the modal
• Before/after proof carousels and a live "just ordered" social-proof ticker
• Floating Apply / Messenger CTAs that swap as the prospect scrolls past the packages

The lead-ops backend. This is the part most "landing pages" skip:

• Leads / Applicants / Customers — three tabs in a bound Google Sheet via Apps Script. Every Stage-1 submit upserts a Lead; every Stage-2 commitment upserts an Applicant; both roll up to one Customer.
• Identity resolution. An order matches an existing person if phone (canonicalized to the last 10 digits), email (lowercased), or Facebook handle matches — name is never a match key, so two applications under different names don't fork into two customers, and extra numbers/emails append to the same record.
• Deposit receipts to Drive. Stage-2 uploads are base64-posted to the Apps Script, saved into a Drive folder, and surfaced as an inline thumbnail in the Sheet — re-uploads trash the old file.
• Order identity, not session identity. Each order carries a unique reference from a localStorage session id, cleared on final Messenger confirm, so a repeat applicant is a genuinely new order rather than an overwrite.

The attribution layer. The Meta Pixel funnel fires PageView on load, AddToCart on each package add, InitiateCheckout on modal open, Lead on Stage-1 submit, and Purchase on the ₱1,000 commitment — each with an event ID so the browser pixel and Meta's automatic Conversions API dedup cleanly. A separate Contact event on the Messenger CTAs measures the engagement gap, but ads only ever optimize for Lead and Purchase.

The live funnel — tap to open it in a new tab:

Open live ↗Open live ↗

Performance & SEO

The optimization pass was driven by a real PageSpeed Insights run, not assumptions. The score profile pointed at page weight on a throttled mobile pipe — TBT was 0 and CLS was near-zero, so this was never a JavaScript or layout problem.

• Render-blocking fonts removed from the critical path. The Google Fonts stylesheet was the single biggest cost on mobile. Switching it to a preload + media="print" onload swap (with a <noscript> fallback) took it off the first-paint path without breaking font rendering — the largest score mover.
• Hero video re-encoded. Down-scaled and re-compressed from the 1080p source, cutting the hero from ~2.2 MB to ~1.2 MB (−47%) with faststart for progressive playout.
• Cache headers via a CF Pages _headers file — long max-age + stale-while-revalidate for static assets, must-revalidate for the HTML so content edits still ship.
• SEO to 100. PageSpeed SEO had capped at 92 because Cloudflare Pages was serving the HTML at /robots.txt (SPA fallback) and Lighthouse parsed it as a broken robots file. Adding a real robots.txt + sitemap.xml, plus a canonical tag and an Organization/WebSite/WebPage JSON-LD graph linking back to the main brand, took SEO to 100 on mobile and desktop.

Outcome

The funnel is live at resellers.shinjiruwellness.ph on Cloudflare Pages — $0 hosting, custom subdomain, one self-contained page. Applicants flow into a three-tab Google Sheet with phone/email/Facebook identity resolution; deposit receipts land in Drive as inline thumbnails; the Meta Pixel funnel (Lead at Stage 1, Purchase at Stage 2) is live with automatic Conversions API for server-side resilience. The performance pass took it off the render-blocking-fonts critical path, cut the hero nearly in half, and lifted PageSpeed SEO to 100.

What I'd repeat

Make the page the system of record. Because PH recruitment funnels into Messenger — which discards everything but a single ref — a landing page that just deep-links to a chat captures nothing. Building the Leads/Applicants/Customers model into the page itself, with identity resolution on phone/email/Facebook rather than name, means every applicant is counted once and tracked across return visits, with no account system and no database to host.

Own the whole stack on free tiers. Design, build, Cloudflare Pages deploy, Apps Script backend, Meta Pixel + automatic CAPI, and a measured performance pass — one operator, end to end, on tooling the client already pays nothing for. There's nothing custom to maintain beyond one HTML file and one script, and the funnel method is reusable for the next recruitment page without rebuilding any of it.