Shopper Acquisition & Engagement Playbook — Puerto Rico

The Acquisition Flywheel

Every channel exists to do one of two jobs: capture a phone number against an identity, or close the loop from offer to verified redemption. WhatsApp sits at the center because it's both the engagement surface and the identity key — everything else feeds it or feeds off it.

01QR / Social / Retailer Post

→

02WhatsApp Opt-In
(phone captured)

→

03Offer Clip
(WA, App, or Web)

06Shopper Forwards Deal
(Earned Sharing)

←

05WhatsApp Retention Nudge

←

04POS Redemption
(TLog match on phone)

Why this ordering matters

Acquisition channels (QR, retailer social, earned shares) are cheap and infinite. WhatsApp opt-in is the one irreversible conversion event — it's where an anonymous shopper becomes a phone-keyed identity Cachealo can measure for life. Everything upstream of step 2 should be designed to push toward it; everything downstream should be designed to make step 6 happen without being asked twice.

Channel 01

Primary engagement, identity capture & redemption channel

WhatsApp is not a marketing channel for Cachealo — it's the data layer's front door. The phone number a shopper opts in with is the Shopper key that later matches against the POS TLog at redemption.

Hard constraint: Meta has blocked outbound WhatsApp marketing to US/PR +1 numbers since April 2025. The MVP must run on CTWA-inbound only — shoppers initiate the thread via a Click-to-WhatsApp ad, QR scan, or social link. Cachealo cannot cold-blast a phone list.
Welcome flow: first message confirms what the shopper is signing up for (offers from named retailer, not generic spam) and captures consent explicitly.
Offer delivery: respects the 24-hour session window and approved message template categories; cadence tuned to the 4.3 offers/month assumption already in the financial model — not a daily blast.
Redemption loop closure: post-purchase confirmation message ties the receipt back to the offer, reinforcing to the shopper that the deal "worked" — the single highest-leverage trust moment in the funnel.
Replenishment nudges: timed against basket-cadence signals from TLog data, not a fixed calendar — buy-cycle-aware, not spray-and-pray.

Design implication: every other channel's job is to get a shopper into this thread, not to replace it.

Opt-in cost: QR / Social / Retailer Post

All three opt-in sources are shopper-initiated — the shopper taps a wa.me link and sends the first message. That distinction drives what's free and what isn't:

Organic entry (QR, retailer social post, earned share): opens the standard 24-hour customer-service window. Every message Cachealo sends back inside that window — welcome, first offer, app nudge — is free, with no cap on count.
Paid Click-to-WhatsApp ads (not part of the launch plan, but worth knowing if it's added later for a boosted campaign, e.g. the K-beauty corridor) get a bonus 72-hour Free Entry Point window on top of the 24-hour window once Cachealo replies. The organic QR/social/post flow doesn't get this automatically — only paid Meta ads with a "Send Message" button do.
Once the window closes with no reply from the shopper, any further message needs a pre-approved template, billed per message: Utility templates (redemption reminders, "your offer is ready") run roughly 80–90% cheaper than Marketing templates (weekly deal drops) — a few cents per message either way, billed against the U.S. rate card since Puerto Rico numbers carry the +1 country code.
Design implication: structure the welcome flow to invite a reply ("Reply YES to see this week's deals") — every reply reopens the free window. Classify redemption confirmations and reminders as Utility wherever the content is genuinely transactional; Meta will reclassify (and re-bill) a Utility template as Marketing if it detects promotional content inside it.

Nudging the shopper toward the app

The app nudge is its own message, sequenced after the shopper has already gotten value — not bundled into the welcome message:

Message 1 (free, in-window): welcome + first offer. No app mention yet — the job here is proving the WhatsApp loop works.
Message 2 (free, in-window, after 2–3 offers clipped or the first redemption): "Want every deal one tap away, even without opening WhatsApp? Add Cachealo to your home screen." with a plain link.
Critical detail: that link has to open in the shopper's actual browser, not WhatsApp's in-app webview — "Add to Home Screen" is a browser-level action that doesn't exist inside any webview, WhatsApp's included. Sending it as a plain free-form text message (not a button on a structured template) keeps it opening externally under WhatsApp's current behavior.
Reminder follow-up for shoppers who haven't installed after a few days, sent once the free window has closed, needs an approved Utility template — a small but real per-message cost worth budgeting for at scale, not assumed free.

Where WhatsApp's in-app webview fits

WhatsApp now opens links from structured business messages inside its own in-app browser by default, so the shopper never leaves the chat. That's the right behavior for most taps — except one:

Use the in-app webview for: viewing this week's offer catalog, an offer's detail page, and pulling up the dynamic redemption barcode. None of these need a real browser tab — staying inside the chat is strictly better here.
Force the external browser for: the "Add to Home Screen" install link only. No webview — WhatsApp's or anyone else's — can run that install flow, so this one link needs to land in actual Safari or Chrome chrome, sent as a free-form message rather than a templated CTA button.

Channel 02

Cachealo Website

Organic front door, account hub, install surface

SEO & trust anchor: the place a skeptical shopper lands to verify Cachealo is real before opting into WhatsApp — especially important since the brand is unfamiliar and the ask is a phone number.
Retailer-branded landing pages: Selectos and Farmacias Aliadas each get a themed offer catalog page reinforcing "your store's deals," not a third-party platform.
PWA install surface: the website is also where the "Add to Home Screen" prompt for the app lives (see deep dive below) — website and app are the same codebase surfaced differently.
K-beauty corridor landing pages: dedicated brand-partner pages for the acrossB/Puerto Rico Supplies/Precioso lane, separate from the core grocery catalog.

Channel 03

In-Store QR Codes

Physical-to-digital bridge at the point of decision

Placements: shelf-talkers, endcaps, register/checkout signage, printed receipts, and — for the pharmacy channel — the Farmacias Aliadas counter and HABA/Caravan sampling tables.
Default destination is WhatsApp opt-in, not a web page. Since the WA thread is where identity capture and the redemption loop actually live, a QR that lands on a generic webpage is a wasted impression. Web landing is the fallback only for shoppers without WhatsApp installed.
Receipt QR: doubles as a post-purchase loop-closer — "see what else is on sale" pointing back into the WA thread, reinforcing the habit loop at the moment of highest attention (right after paying).
Pharmacy-specific use: Caravan four-stage entry sequence (sampling → first coupon → follow-on coupon → LTV tracking) for new K-beauty brand launches at Farmacias Aliadas uses QR at the sampling table as stage-one capture.

Channel 05

Earned Social Media (Sharing)

Compounding, zero-cost acquisition loop

WhatsApp forwarding is already a Puerto Rican shopping habit — family and neighborhood group chains routinely pass along deals. Cachealo's job is to make the shareable unit (an offer card/link) good enough to forward, not to invent new behavior.
Post-redemption share prompt: immediately after a successful redemption confirmation, a light nudge — "send this deal to someone else" — when goodwill is highest.
Referral structure: a small bonus for both referrer and referred shopper on first redemption, funded out of the same offer economics already modeled (clip rate / redemption rate assumptions).
UGC tie-in for K-beauty Caravan: sampling-stage shoppers are natural earned-content sources for new brand launches at Precioso/Farmacias Aliadas.

Deep Dive: Cachealo App — Native vs PWA

This is the one channel decision with real engineering cost attached, so it gets a full evaluation rather than a default answer. The short version: the app is a utility surface, not the engagement engine — that job already belongs to WhatsApp — and that single fact changes the calculus for which weaknesses actually matter.

Comparison matrix

Criterion	Native App	PWA
Time to ship	6–10 weeks build, plus App Store / Play Store review queues for every release	Days; ships on the existing web stack, no review cycle
Multi-retailer scaling	Each co-branded retailer variant risks a separate build/listing, or heavy white-label tooling	One codebase; retailer theming served dynamically by URL/config — matches the neutral infrastructure model
Push notifications	Full native push, Live Activities, Time-Sensitive interrupts (iOS + Android)	Android: full parity. iOS: works only after manual "Add to Home Screen" (no auto-install prompt); no Live Activities; subscriptions can silently lapse
Offline / background refresh	Background fetch — fresh prices/cart before the app is even opened	No Background Sync API on iOS; content refreshes only when the user opens the app
QR / camera scanning	Full native camera APIs	getUserMedia covers in-store QR scanning on both Android and iOS Safari — no material gap here
Hardware access (NFC, Bluetooth)	Full access on both platforms	iOS blocks Web NFC, Web Bluetooth, WebUSB; Android is more permissive
Dev & QA cost	Two platform codebases (or React Native), plus OEM/version QA matrix	One codebase reusing the existing web stack; small lean team (Sebastian) can own it
Discovery	App Store / Play Store search, "legitimacy" badge of being listed	No store presence — but Cachealo's acquisition already runs through WhatsApp/QR/retailer social, not organic store search
Update velocity	Subject to review queue (typically 1–3 days, longer if flagged)	Instant server-side deploy

Puerto Rico market context — Android-predominant

Puerto Rico's shopper base skews predominantly Android. That removes most of the iOS push friction from the decision before it's even weighed — Android's PWA install prompt, push notifications, and badging all run at near-native parity, with no manual "Add to Home Screen" step required.
For the iOS minority: as of iOS 16.4 (outside the EU, which includes the U.S. and PR), installed PWAs can still receive web push — it just requires the shopper to manually add the site to their home screen first, since there's no automatic install prompt the way Android offers one. As of iOS 26, any site added to the Home Screen now defaults to opening as a standalone web app even without a manifest, a small additional friction reduction.
Worth confirming the exact OS split from real Selectos QR-scan and website traffic once live — it won't change the decision, but it will size how much onboarding effort to spend on the iOS install nudge versus leaving it lightweight.

Decision

Build PWA-first. Do not build native for launch.

Puerto Rico's Android-predominant shopper base removes most of the usual PWA objection. The iOS push/install friction that normally weighs against PWA only applies to a minority of the market here — Android gets near-native install prompts, push, and badging with no gap at all.
WhatsApp already owns real-time engagement and identity capture. The app's job is utility — browse offers, view clipped coupons, find a store, manage account — not push-dependent retention. Whatever iOS push gap remains matters even less when push isn't the primary lever driving the business.
Selectos go-live timeline and team bandwidth don't support a two-platform native build without pulling Sebastian off customer-surface work that's already in the critical path alongside MBS POS testing.
Multi-retailer scaling needs one codebase with dynamic theming — Farmacias Aliadas, future ROFDA stores, and eventual mainland expansion are exactly the case PWA is built for, and exactly the case that breaks down fastest with per-retailer native builds.
QR scanning — the actual in-store mechanic — has no capability gap between native and PWA, so the channel this app most needs to support loses nothing.
Weekly offer-drop cadence doesn't tolerate app-store review queues. A PWA ships changes the same day a campaign needs them.

When to revisit native

This is a phased decision, not a permanent one. Re-open the native question if any of the following becomes true:

A retailer or CPG brand partner contractually requires a native app listing for shelf or marketing reasons.
App-surfaced engagement (as opposed to WhatsApp) becomes a primary KPI, and measured iOS push reliability becomes an actual bottleneck rather than a theoretical one.
A hardware requirement emerges that iOS blocks in-browser (NFC loyalty card tap, Bluetooth in-store beacon navigation).
Funded, dedicated mobile engineering capacity exists post-raise without trading off core POS-integration or data-model work.

Making the dynamic barcode easy to retrieve

If the GS1 8112 redemption code rotates or expires (the anti-fraud behavior the model already assumes), it can't be a static image sent once into a chat — both surfaces need to render the live code on demand, not a stale screenshot.

In WhatsApp: a persistent "My Coupons" quick reply or list message that opens the live barcode page inside WhatsApp's in-app webview — one tap from any point in the thread, no app switch, always pulling the current code rather than a cached image.
In the app/PWA: a fixed bottom-nav "Wallet" tab, one tap from launch, hitting the same live-rendering endpoint WhatsApp uses — so the code is identical and equally fresh on both surfaces.
Worth evaluating for a later phase: Google Wallet supports a native rotating-barcode pass type built for exactly this anti-fraud pattern — the code rotates locally on the device without needing a live connection at checkout, and the pass sits on the lock screen. That fits an Android-predominant market well. Apple Wallet has no equivalent native rotation (Apple passes update via server push instead, which still depends on connectivity), so this would be an Android-first enhancement, not a cross-platform replacement for the WA/app wallet view.

Camera access: QR scans today, product photos later

Worth being precise here rather than assuming uniform behavior, because the two use cases rely on different mechanisms.

The in-store QR opt-in scan — a shopper pointing their phone at a shelf-talker or register QR — is handled entirely by the phone's built-in camera app (both iOS and Android detect QR codes natively and offer to open the link). That's not Cachealo's code at all, and it's fully reliable on both platforms with no caveats.
A future in-app camera feature — a shopper pointing the camera at a product inside Cachealo's own app/PWA for visual search or price lookup — uses the browser's camera API directly. That works seamlessly on Android in any context: a regular browser tab, the installed PWA, or a wrapped app shell.
On iOS, there's one real nuance: the camera API works reliably in a normal Safari tab, but has a known, long-standing reliability issue specifically inside an installed, standalone PWA (the Add-to-Home-Screen shell) — it can fail to prompt for permission or drop the feed. The straightforward mitigation is to run any future camera-dependent screen in a standard browser-tab context rather than the standalone shell, or fall back to the simpler "take a photo" capture flow (which opens the native camera app and returns a still image) instead of a live in-app preview. Given the Android-predominant market here, this is a manageable, well-understood edge case rather than a blocker — but it's worth knowing about now rather than discovering it after the feature ships.

Implementation Roadmap

Sequenced against the Selectos go-live gate, not on a separate timeline.

Phase 0
Pre-launch

Identity capture infrastructure live

WhatsApp CTWA-inbound flow built and tested; Cachealo website live as offer catalog + PWA install surface; in-store QR placed at Selectos pilot stores; Selectos co-branded social content calendar kicked off.

Phase 1
Go-live + 90 days

PWA installable, push live where it works

Push opt-in flow shipped (full on Android, "Add to Home Screen" nudge sequence on iOS); earned-sharing mechanics (forward-to-friend, post-redemption nudge) turned on; actual OS split measured from real Selectos traffic to size the iOS push gap with data instead of assumption.

Phase 2
Multi-retailer scale

Farmacias Aliadas + pharmacy channel

Retailer-themed PWA instance for Farmacias Aliadas; pharmacy-counter QR for the Caravan K-beauty sampling sequence; retailer social expansion to the pharmacy channel's own following.

Phase 3
Post-proof

Native re-evaluation checkpoint

Revisit the native app decision against the trigger conditions above, using real usage and push-reliability data rather than projections.

Channel KPIs

Channel	Primary metrics
WhatsApp	Opt-in rate from CTWA/QR source; offer clip rate; redemption rate; reactivation rate after a nudge
Website	Visit → PWA-install rate; visit → WhatsApp opt-in rate; bounce rate by retailer landing page
App / PWA	Install rate; push opt-in rate split by iOS vs Android; DAU/MAU; offers clipped in-app vs in-WA
In-store QR	Scan volume by placement type (shelf / endcap / register / receipt); scan → opt-in conversion
Retailer social	Reach; engagement rate; click-through to QR or WhatsApp opt-in
Earned sharing	Share rate per redemption; referred-shopper activation rate; viral coefficient