Skip to content

Choose your integration

Grona offers four integration routes. They differ in where the decision is made, who draws the content and how much code your team writes. Use this page to pick a route for each surface you own, and to see when routes work together.

You add the Grona script to the <head> of your site. Your marketing or growth team builds variations in the Grona dashboard’s visual editor, and the script applies them in the visitor’s browser. No other code is needed for a first campaign. To count conversions beyond what Grona tracks on its own, you add a grona('track', ...) call or a goal snippet.

Choose this when your site is a website you can edit, and you want campaigns without a release for each change. See Website integration overview.

You add the Grona Android or iOS SDK and place a slot view in your layouts, one per placement. Grona draws native components into the slot: a banner, a progress bar towards a threshold, an offer or a message. You theme them with your fonts and colours. When a shopper taps a call to action, the SDK asks your app to add products or open a screen through the host interface you implement.

Choose this when you want campaigns in your app with the least UI work, and the built-in components fit your design. See Grona components.

You ask the SDK for a decision for a placement and draw it with your own views. A decision is a product rail, a bundle, a single product card or an out-of-stock substitute, with its title, products and labels. Your app owns the layout completely. You call the decision’s add, replace or dismiss methods from your own tap handlers, so Grona can log the action.

Choose this when the content must look exactly like the rest of your app, for example a frequently-bought-together rail on the product page. See Patterns for host-rendered decisions.

Your server calls https://api.grona.ai/v1/ with a secret key to create, update, launch, pause and delete website campaigns, to get editor links for their variations and to check that the script is on a page. The campaigns still run through the website script, so the script must be installed.

Choose this when your own platform, such as a CMS or a merchandising tool, should create Grona campaigns without your users opening the Grona dashboard. See Public API overview.

Website script SDK-rendered components Host-rendered decisions Public API
Runs in The visitor’s browser Your Android or iOS app Your Android or iOS app Your backend
Who decides what a visitor sees The script, in the browser The SDK, on the device The SDK, on the device Not applicable: it manages campaigns, the script decides
Who draws the content The script edits your page The SDK draws native components Your app, with its own views Not applicable
Code your team writes The snippet, plus optional conversion calls Initialisation, a host interface, slot views, consent Initialisation, a host interface, decision listeners and your own views, consent HTTPS calls with a secret key
Start here Quickstart: website Quickstart: Android Host-rendered decisions (Android) Quickstart: Public API
  • Website and apps. A retailer with a website and apps installs the script on the site and an SDK in each app. Each surface has its own campaigns and its own identifiers: a workspace id for the website and a workspace key for the apps.
  • Both rendering modes in one app. The choice is per placement, not per app. You can show Grona banners in a slot on the home screen and render a product rail yourself on the product page. See Rendering modes.
  • Public API and website script. The API creates and manages campaigns; the script runs them. Install and verify the script first, then call the API. The API’s verify call checks a page for you.
  • Offers in apps and your backend. An offer that carries money, such as 10% off this order, renders only when the SDK holds a grant for that shopper. Your backend fetches grants and verifies them again when the order is placed. See Offers and grants and Grants and order verification.