Can Made With Intent Support Native Apps?
Short answer: yes, with important caveats. We’re a web‑first, real‑time intent platform. We can support app as a data/analytics channel, but we don’t yet offer full app‑parity or plug‑and‑play in‑app personalisation.
What We Can Do Today
1. Ingest app data via server‑side APIs
If your team can send events from your native apps (iOS/Android) to our endpoints, we can:
Accept key events such as:
Screen/page views
Key clicks / taps
Add‑to‑cart / checkout / order events
User / session identifiers and app identifiers
Treat app as another “container” alongside web, so journeys can be linked across channels.
2. Run intent models and generate predictions
On top of those events, we can:
Run our models (or a lighter, app‑specific variant where needed).
Produce predictions and session summaries at visitor/session level (e.g. buy/leave/return likelihood, simple tiers of intent).
Feed those into:
Your CDP
Your data warehouse
Your own analytics / BI stack
For many teams (especially where data science owns activation), this is enough to:
Build app‑inclusive audiences and segments
Analyse drop‑off, conversion, and cross‑channel journeys
Enrich existing ML models with intent signals
3. Use app data in a PoC (analytics‑only)
For a typical 3–4 month PoC:
App support is insights‑only, not in‑app experiences.
We focus on:
Getting reliable app events in
Proving that predictions are stable and useful
Delivering reporting and exports your team can act on
What We Can’t (or Won’t) Do Yet
1. No native SDK / plug‑and‑play app integration
We don’t currently ship:
A native SDK for iOS/Android
One‑click GTM‑style setup for app
Your engineering team must own the tracking implementation and send data to us server‑side.
2. No full real‑time in‑app activation
Today we don’t:
Decide in real time which banner/experience to show inside the native app UI
Offer feature‑flag style decisioning embedded directly in the app
Any activation during a PoC is expected to be:
Downstream (via your CDP, marketing tools, or in‑house models)
Based on the predictions and summaries we send you, not our UI rendering in‑app
3. Less behavioural richness than web
Because native apps don’t send us the same passive signals by default, unless you explicitly track and send them:
We may not see:
Scroll depth / micro‑movements
Time‑on‑element (time beacons)
Every minor interaction
That means:
Fewer data points per journey than web
Intent predictions will be good enough for high/low intent and simple segments, but not as granular as on web
Implementation & Responsibilities
To make app support work, we’ll need:
From your side
Engineering resource to:
Implement server‑side event tracking in the app(s)
Ensure events are de‑duplicated, well‑structured and enriched (screen name, page type, value, identifiers, etc.)
Avoid mis‑configurations (e.g. infinite loops that spam events)
A clear owner (often data/engineering) for:
Monitoring the integration
Defining how predictions will be used downstream
From our side
Event ingestion and validation
Running models and generating predictions/session summaries
Delivering those into:
Metabase (or equivalent analytics)
Your CDP / warehouse via integrations or exports
Guardrails on our infrastructure (rate limiting / shielding) to keep the platform stable
If you’re happy with app as a data and prediction channel (rather than a plug‑and‑play personalisation SDK), we can support it and will happily share a detailed event spec and technical brief with your team, as well as discuss adding it to your existing contract. Please reach out to your CSM to explore further.