Personalized product recommendations — the same engine that powers recommendation widgets on your website — delivered inside your native iOS or Android app. The profile is shared across surfaces, so someone who browsed jackets on your site gets relevant picks the moment they open the app, rather than starting from scratch.
In the panel: New campaign › App / API › Product Recs for Apps.
Before you start
The SDK has to be installed and reporting first. Installation for both platforms, the initialisation code, and how to confirm data is arriving are in Targeting & Personalization for Mobile Apps. If your device does not appear in Real time visitors, stop and fix that first — recommendations cannot be produced for a user Personyze cannot see.
You also need a product catalog in Personyze. See the products object for pushing one over the API, or upload a feed in the panel.
The campaign steps
Six steps: Set up, Catalog, Interactions, Content, Target and Performance.
Two things to notice. There is no QA step — app campaigns are validated in a build, not in the panel. And Content comes before Target: you design the recommendation first, then decide who receives it.
1. Set up
Confirms the SDK integration. Covered in the article linked above.
2. Catalog
Your product catalog has to be in place and current. Each product needs at least an internal ID, a title and an image URL — recommendations with no image render as empty boxes in an app just as they do on the web. Keep is_in_stock accurate, or you will recommend things people cannot buy.
3. Interactions
This is the step that decides whether recommendations are any good, and the one most often skipped.
The engine learns from what people do with products: viewed, added to cart, purchased. On a website Personyze can often detect these automatically. In an app it cannot — there is no DOM to watch. Your app must report them explicitly through SDK calls.
At minimum report product views and purchases. Without interaction data, algorithms like “bought together” and “popular” have nothing to compute from, and the widget will come back empty or fall back to a generic list.
If you also sell on the web, the two streams merge into one profile — so in-app browsing improves website recommendations and vice versa.
4. Content
Choose the recommendation algorithm and the shape of the response. For apps there are two rendering options:
- HTML (WebView) — Personyze returns a rendered widget you drop into a WebView. Quickest path, and the layout can be changed later without shipping an app update.
- JSON — Personyze returns the chosen products as structured data and your app lays them out natively. Better performance and a native feel; more work up front.
If you are returning JSON, choose the fields your app needs in the response — title, price, image URL, product URL, and any custom catalog fields you want to display.
5. Target
Who sees the recommendation. All standard targeting applies. A common pattern is to show different algorithms to different people — newest arrivals to first-time users, “bought together” to people with purchase history.
6. Performance
Results once it is live: how often the recommendation was shown, engaged with, and what it contributed.
Validating it
- Confirm your device appears in Real time visitors.
- Report a few product views from the app, and check they land against your session.
- Widen the audience so it certainly matches you, and confirm recommendations arrive and are not empty.
- Narrow the rules back and confirm the behaviour changes.
An empty result almost always means step 2 or 3 of the campaign — a catalog that did not import, or interactions that are not being reported — rather than a targeting problem.