Gaperon (latest)
🆕 🚨 What's new?
The visitor targeting workflow has been simplified. You do not need to register the visitor navigation anymore.
Thus, the method registerUserNavigation(navigationOption: NavigationOption) is now deprecated.
Now, you manage targeting using only these 2 methods:
To engage the visitor, call
activateTargetingRule(targetingRule: TargetingRule)(as you already do).To stop engaging the visitor, calls
deactivateTargetingRule()(this is new).
Between these 2 calls, the iAdvize Mobile SDK automatically updates the targeting rule availability (every 30 seconds) and updates the chat button accordingly. If the update fails (e.g.: if there is no connection), you do not need to perform any special actions. The iAdvize SDK will try to update it again 30 seconds later.
// Activating a new rule.
// - Before:
IAdvizeSDK.targetingController.registerUserNavigation(NavigationOption.ActivateNewRule(yourOtherTargetingRule))
// - After (if there is already a targeting rule activated, it is replaced):
IAdvizeSDK.targetingController.activateTargetingRule(yourOtherTargetingRule)
// Deactivating the rule.
// - Before:
IAdvizeSDK.targetingController.registerUserNavigation(NavigationOption.ClearActiveRule)
// - After:
IAdvizeSDK.targetingController.deactivateTargetingRule()
// Register new screen.
// - Before:
IAdvizeSDK.targetingController.registerUserNavigation(NavigationOption.KeepActiveRule)
// - After:
// Nothing to do.// Activating a new rule.
// - Before:
IAdvizeSDK.shared.targetingController.registerUserNavigation(navigationOption: .activateNewRule(targetingRule: yourOtherTargetingRule))
// - After (if there is already a targeting rule activated, it is replaced):
IAdvizeSDK.shared.targetingController.activateTargetingRule(targetingRule: yourOtherTargetingRule)
// Deactivating the rule.
// - Before:
IAdvizeSDK.shared.targetingController.registerUserNavigation(navigationOption: .clearActiveRule)
// - After:
IAdvizeSDK.shared.targetingController.deactivateTargetingRule()
// Register new screen.
// - Before:
IAdvizeSDK.shared.targetingController.registerUserNavigation(navigationOption: .keepActiveRule)
// - After:
// Nothing to do.⚙️ Prerequisites
There are a few steps required before you start integrating the iAdvize Mobile SDK.
💬 Setting up your iAdvize environment
Before integrating the Mobile SDK, you need to check that your iAdvize environment is ready to use (i.e. you have an account ready to receive and answer to conversations from the Mobile SDK). You will also need some information related to the project for the Mobile SDK setup. Please ask your iAdvize administrator to follow the instructions available on the Mobile SDK Knowledge Base and to provide you with the Project Identifier as well as a Targeting Rule Identifier.
Your iAdvize administrator should already have configured the project on the iAdvize Administration Desk and created an operator account for you. If it is not yet the case please contact your iAdvize Technical Project Manager.
🎯 Understanding Mobile SDK: triggers & targeting
Key differences: Mobile SDK vs Web
Web:
iAdvize automatically detects visitor behavior
Targeting rules include criteria (URL patterns, visitor segments, timing conditions)
Triggers fire automatically based on Admin configuration
Mobile SDK:
YOU implement ALL trigger detection logic in your app code
Targeting rules are routing identifiers ONLY (no criteria, no automatic triggering)
The Mobile SDK provides the conversation infrastructure, not behavior detection
What the Mobile SDK provides vs what you should implement
✅ Mobile SDK provides:
activateTargetingRule(uuid)- Shows chat button if operator/bot availabledeactivateTargetingRule()- Hides chat buttonAutomatic 30-second availability checks
Conversation interface and message handling
❌ You must implement:
Detecting user behavior (idle time, scroll events, button taps, navigation)
Implementing business rules (show after 10s on product page, hide on checkout, etc.)
Frequency control (max 1x per session, cooldown periods)
Session tracking and visitor preferences
Deciding WHEN to call
activateTargetingRule()
Example architecture
YOUR APP detects: "User idle 8 seconds on homepage"
YOUR APP decides: "Show chat button" (checks frequency cap, user preferences)
YOUR APP calls:
activateTargetingRule("homepage-uuid")Mobile SDK checks: Operator/bot available?
Mobile SDK shows: Chat button (if available)
💻 Connecting to your iAdvize Operator Desk
Using your operator account please log into the iAdvize Desk.
If you have the Administrator status in addition to your operator account, you will be directed to the Admin Desk when logging in. Just click on the Chat button in the upper right corner to open the Operator Desk.
The iAdvize operator desk is the place where the conversations that are assigned to your account will pop up. Please ensure that your status is “Available" by enabling the corresponding chat or video toggle buttons in the upper right corner:

If the toggle button is yellow, it means you have reached your maximum simultaneous chat slots, please end your current conversations to free a chat slot and allow the conversations to be assigned to you. If the toggle is red you are not available to chat.
🔐 Ensuring the Mobile SDK integrity
Before downloading the iAdvize Mobile SDK artifacts you can verify their integrity by generating their checksums and comparing them with the reference checksums available.
Reference checksums are available:
in the GitHub release note
in the dedicated spreadsheet
The iAdvize Android SDK consists of an archive (aar file) and a Maven project description (pom file), you can generate their checksums using the following commands (replace x.y.z by the SDK version you are checking):
This ensures that the online packages are valid. In order to check those checksums on the fly, this process can be automated via Gradle by adding a metadata verification xml file at $PROJECT_ROOT/gradle/verification-metadata.xml:
With this file present in your project structure, Gradle will automatically check the artifacts checksums before integrating them into your app. Please note that you will have to do this for all dependencies used in your project. To help you with that, verification-metadata.xml for the Mobile SDK sub-dependencies is delivered alongside the Mobile SDK. Those subdependencies checksums have been generated through the Gradle generation feature and not verified.
Reference checksums are available:
in the GitHub release note
in the dedicated spreadsheet
Swift Package Manager integration
The iOS SDK only consists of an archive (zip file). You can generate its checksums using the following command (replace x.y.z by the SDK version you are checking):
SPM will also automatically verify that the checksum of the artifact it downloads correspond to the one described in the Package.swift available in the public repository (it's a SHA2-256 checksum).
CocoaPods integration
The iAdvize iOS SDK consists of an archive (zip file) and a Cocoapods project description file (podspec file). You can generate their checksums using the following commands (replace x.y.z by the SDK version you are checking):
After downloading the SDK through CocoaPods, additional verifications can be made, first by comparing the podspec checksum at the end of the generated Podfile.lock with the SHA1 podspec reference checksum.
The downloaded framework integrity can also be checked by generating the local pod files checksums and comparing them with the online reference ones:
Our React Native SDK plugin is hosted on an external platform called Node Package Manager (NPM) that already has internal checksum validation strategies in order to ensure that the downloaded plugin code (the wrapper code) is untampered.
Our Flutter SDK plugin is hosted on an external platform called pub.dev, that already has internal checksum validation strategies in order to ensure that the downloaded plugin code (the wrapper code) is untampered.
⚙️ Setting up the Mobile SDK
1️⃣ Setting up the Mobile SDK into your project configuration
First of all, to be able to use the Mobile SDK you need to add the Mobile SDK dependency into your project. Some configuration steps will also be needed in order to use it.
Add the iAdvize repository to your project repositories inside your top-level Gradle build file:
Add the iAdvize Mobile SDK dependency inside your module-level Gradle build file (replace x.y.z by the latest SDK version available):
If you have build problems this may come from compatibility issues with the Android configuration, here are the versions used by the iAdvize Mobile SDK:
Target SDK
35
Compile SDK
35
Minimum SDK
24
Build Tools
35.0.0
Kotlin
2.1.10
Gradle
8.13
Android Gradle Plugin
8.9.0
After syncing your project you should be able to import the iAdvize dependency in your application code with import com.iadvize.conversation.sdk.IAdvizeSDK
You will then need to provide a reference to your application object and initialize the SDK with it.
In your AndroidManifest.xml declare your application class:
This class should then initialize the SDK:
⌨️ In-context example:
From Xcode go to File > Add Packages, then paste the iAdvize Messenger SDK URL https://github.com/iadvize/iadvize-ios-sdk in the top-right search bar. Select the versioning strategy fitting your app then click on Add Package.
You should then be able to import the iAdvize dependency in your application code using import IAdvizeConversationSDK
⌨️ In-context example: Import
Add this line to your Podfile, inside the target section (replace x.y.z by the latest SDK version available, and choose the versioning strategy fitting your app):
iAdvize Messenger SDK requires a minimum iOS platform of 13.0.
After running pod install you should be able to import the iAdvize dependency in your application code with import IAdvizeConversationSDK
⌨️ In-context example:
Download the library from NPM using the following command:
Alternatively, you can use Yarn:
The SDK API is then available via the following import:
In your android/build.gradle file, and add the iAdvize SDK repository. You also need to ensure that you are using the right Android framework to build (iAdvize Mobile SDK is built with Android target 35):
iAdvize Mobile SDK requires a minSdkVersion >= 24.
On Android, the iAdvize Mobile SDK needs to be initialized before use to allow several functionalities to work. For instance, the default floating button use an ActivityLifecycleController that must be started before the main ReactNative activity is created, otherwise the controller won't be able to trigger the button display. Thus you need to add those lines in the android/app/src/main/java/yourpackage/MainApplication.java to initialize the SDK properly:
Add this line to your Podfile, inside the target section (replace x.y.z by the latest SDK version available, and choose the versioning strategy fitting your app):
iAdvize Mobile SDK requires a minimum iOS platform of 13.4
Once this is done, make sure to go to ios folder and install CocoaPods dependencies:
Download the SDK as well as the expo-build-properties library from NPM using the following command:
Configure the build properties using expo-build-properties in the app.json file:
For that step you will need to download the iAdvize Mobile SDK Expo Plugin configuration file and save it alongside the app.json file of your project.
Afterwards you can generate the native code using the traditional Expo command:
Download the library from pub.dev using the following command:
The SDK API is then available via the following import:
In your android/build.gradle file, and add the iAdvize SDK repository:
You also need to ensure that you are using the right Android framework to build (iAdvize Messenger SDK is built with Android target 35), as a good practice, also check that you are using the latest Kotlin version in android/build.gradle (you can find the version used in the plugin through its README file)
iAdvize Messenger SDK requires a minSdkVersion >= 24.
Add this line to your Podfile, inside the target section (replace x.y.z by the latest SDK version available, and choose the versioning strategy fitting your app):
iAdvize Messenger SDK requires a minimum iOS platform of 13.4
Once this is done, make sure to go to ios folder and install CocoaPods dependencies:
2️⃣ Activating the Mobile SDK
Now that the Mobile SDK is available into your project build, let's integrate it into your app, first by activating it. Activation is the step that logs a visitor into the iAdvize flow.
You can choose between multiple authentication options:
Anonymous
For an unidentified visitor browsing your app.
Simple
For a logged in visitor in your app. You must pass a unique string identifier so that the visitor will retrieve his conversation history across multiple devices and platforms. The identifier that you pass must be unique and non-discoverable for each different logged-in visitor.
Secured
Use it in conjunction with your in-house authentication system. You must pass a JWE provider callback that will be called when an authentication is required, you will then have to call your third party authentication system for a valid JWE to provide to the Mobile SDK. For a full understanding of how the secured authentication works in the iAdvize platform you can refer to this section.
To activate the Mobile SDK you must use the activate function with your projectId (see the Prerequisites section above to get that identifier). You have access to callbacks in order to know if the SDK has been successfully activated. In case of a Mobile SDK activation failure the callback will give you the reason of the failure and you may want to retry later.
Once the iAdvize Mobile SDK is successfully activated, you should see a success message in the console:
3️⃣ Logging the visitor out
You will have to explicitly call the logout function of the iAdvize Mobile SDK when the visitor sign out of your app.
4️⃣ Displaying logs
To have more information on what’s happening on the Mobile SDK side you can change the log level.
You can get a description of the Mobile SDK status at any time by using the debugInfo API:
This will generate a JSON object with the Mobile SDK status information, encoded into a string that you can easily add into your bug reporting tool payload:
💬 Starting a conversation
To be able to start a conversation you will first have to trigger a targeting rule in order for the default chat button to be displayed. The chatbox will then be accessible by clicking on that chat button.
1️⃣ Configuring the targeting language
The targeting rule configured in the iAdvize Administration Panel is setup for a given language. This means that if, for example, you setup a targeting rule to be triggered only for EN language and the current visitor’s device is setup with a different targeting language (for instance FR), the targeting rule will not trigger.
By default, the targeting rule language used is the visitor’s device current language. You can force the targeting language to a specific value using:
This language property is NOT intended to change the language displayed in the SDK. It is solely used for the targeting process purpose.
2️⃣ Activating a targeting rule
What is a targeting rule in Mobile SDK?
Unlike web targeting rules (which include criteria and automatic triggering), Mobile SDK targeting rules are routing identifiers only:
❌ No behavioral criteria (URL patterns, dwell time, scroll depth)
❌ No automatic triggering based on visitor behavior
✅ Routes conversations to specific routing rules/teams/bots
✅ Checks operator/bot availability
Your responsibility:
Detect user behavior in your app (navigation, idle time, button taps)
Implement business logic for WHEN to activate rules
Call
activateTargetingRule()when YOUR conditions are met
SDK responsibility:
Check if operator/bot is available for this targeting rule
Show/hide chat button based on availability
Update availability every 30 seconds
Best practice: Create one targeting rule per app context:
Homepage →
activateTargetingRule("homepage-uuid")Product page →
activateTargetingRule("pdp-uuid")Cart →
activateTargetingRule("cart-uuid")
Each rule can route to different teams/bots while you control the triggering logic.
See Understanding Mobile SDK: triggers and targeting for architecture details.
Calling activateTargetingRule
Using a targeting rule UUID (see the Prerequisites section above to get that identifier), you can engage a visitor by calling:
If all the following conditions are met, the default chat button should appear:
the targeting rule exists and is enabled in the administration panel
the targeting rule language set in the Mobile SDK matches the language configured for this rule
an operator/bot assigned to this rule is available to answer (connected and with a free chat slot)
3️⃣ Initiating the conversation
Once the default chat button is displayed, the visitor tap on it to access the chatbox. After composing and sending a message a new conversation should pop up in the operator desk.


4️⃣ Following visitor navigation
While your visitor navigates through your app, you may want to update the active targeting rule in order to engage him/her with the best conversation partner at any time. To do so, simply activate the new rule. It will replace the previous one.
5️⃣ Deactivating a targeting rule
When you do not want to engage the visitor anymore, simply deactivate the targeting rule.
6️⃣ Frequency control & proactive messaging limitations
Reactive-only nature
The Mobile SDK is reactive-only:
✅ Visitor must tap the chat button to start a conversation
❌ Cannot push messages to trigger conversation start
✅ Push notifications work for ongoing conversations (operator/bot replies)
❌ Cannot proactively message visitors to initiate conversation
While workflows/AI Shopping Assistant can "proactively" greet and guide visitors WITHIN a conversation, the visitor must first open the chatbox.
Frequency capping
The Mobile SDK does NOT provide built-in frequency control.
Track locally:
How many times
activateTargetingRule()is called per session/dayCooldown periods (don't show for X hours after dismissal)
Visitor preferences ("don't show again")
Analytics for optimization
While the SDK doesn't control frequency, iAdvize tracks metrics for analysis:
TARGETING_RULE_DISPLAY_NUMBER- Button display countTARGETING_RULE_TRIGGERED- Conversation start count
Access via GraphQL API - Pre-aggregated Indicators for historical analysis and optimization (not real-time control).
👋 Configuring GDPR and welcome message
1️⃣ Adding a welcome message
As seen above, the chatbox is empty by default. You can configure a welcome message that will be displayed to the visitor when no conversation is ongoing.
When no conversation is ongoing, the welcome message is displayed to the visitor:

2️⃣ Enabling GDPR approval
If you need to get the visitor consent on GDPR before he starts chatting, you can pass a GDPROption while activating the SDK. By default this option is set to Disabled.
If enabled, a message will request the visitor approval before allowing him to send a message to start the conversation:

This GDPR option dictates how the SDK behaves when the visitor taps on the More information button. You can either:
provide an URL pointing to your GPDR policy, it will be opened on visitor click
provide a listener/delegate that will be called on visitor click and you can then implement your own custom behavior
If your visitors have already consented to GDPR inside your application, you can activate the iAdvize Mobile SDK without the GDPR process. However, be careful to explicitly mention the iAdvize Chat part in your GDPR consent details.
⌨️ In-context example:
⌨️ In-context example:
If you set both the listener and an URL, the listener will take priority.
🎨 Branding the Chatbox
The ChatboxConfiguration object that we used in the previous section to customize the welcome and GDPR messages can also be used to change the Chatbox UI to better fit into the look and feel of your application.
You should setup the configuration before presenting the chatbox. If you call this method while the chatbox is visible, some parameters will only apply for new messages or after closing/reopening the chatbox.
1️⃣ Updating the font
The font used in the Chatbox can easily be updated using your own font:
Even if the UIFont constructor needs a size attribute, the exact font size and traits are automatically chosen and the font is scaled to the current Dynamic Type setting.
2️⃣ Styling the navigation bar
Some parts of the he toolbar/navigationbar appearing at the top of the Chatbox can also be customized:
the background color
the main color
the title
3️⃣ Changing the Chatbox colors
The displayed messages colors can be customized, either the ones from the agent (incomingMessages) or the ones from the visitor (outgoingMessages):
the message bubble background color
the message text color
the message bubble stroke/border color
the accent color, used for all message controls (same color for both agent & visitor): quick answers, file messages, send button, typing indicator...
4️⃣ Using a brand avatar
The operator avatar displayed alongside his messages can be updated for branding purposes. You can specify a drawable either via an URL or a local resource.
If you fill both fields, incomingMessageAvatarImageName will take priority over incomingMessageAvatarURL.
If you fill both fields, incomingMessageAvatarImageName will take priority over incomingMessageAvatarURL.
GIFs are not supported.
5️⃣ Presenting a smaller Chatbox
The Chatbox can be presented in a compact mode.
The visitor can then expand the chatbox manually. The chatbox is automatically expanded when the keyboard opens. This compact mode can be enabled by using a flag in the ChatboxConfiguration.
🎨 Branding the Default Floating Button
By default, the Mobile SDK uses its own Default Floating Button for the visitor to engage in the conversation. This Default Floating Button display process is automated by the Mobile SDK and works out of the box. You have however limited possibilities to brand it to your needs.
The Default Floating Button can be parametrized, both in its look (colors / icon) and position (anchor / margins) using the appropriate configuration:
⌨️ In-context example: Default Floating Button Configuration
The Default Floating Button will use hardcoded icons and the ChatboxConfiguration.accentColor as background color:
The Default Floating Button is anchored to the bottom left side of the screen. You can modify its placement by specifying the button margins:
The Default Floating Button will use hardcoded icons and the ChatboxConfiguration.accentColor as background color:
The Default Floating Button is anchored to the bottom left side of the screen. You can modify its placement by specifying the button margins:
The Default Floating Button will use hardcoded icons and the ChatboxConfiguration.accentColor as background color:
The Default Floating Button is anchored to the bottom left side of the screen. You can modify its placement by specifying the button margins:
✨ Using a custom chat button
If you are not satisfied with the Default Floating Button look and feel or if you want to implement a specific behavior related to its display you may need to use a custom conversation button.
With a custom button it is your responsibility to:
design the floating or fixed button to invite your visitor to chat
hide/show the button following the active targeting rule availability and the ongoing conversation status
open the Chatbox when the visitor presses your button
1️⃣ Disabling the Default Floating Button
2️⃣ Displaying/hiding the chat button
Understanding availability callbacks
These listeners notify you when:
Targeting rule availability changes (operator/bot becomes available/unavailable)
Availability update fails
Conversation status changes
⚠️ Important distinction:
Availability callbacks (from Mobile SDK) tell you:
"Is an operator/bot available for this targeting rule right now?"
Your business logic (in your app) determines:
"Should I show the chat button based on user behavior, frequency caps, preferences?"
Combined decision logic
To show/hide your custom button, combine BOTH:
✅ Your conditions met? (user behavior, frequency, preferences)
✅ Mobile SDK availability = true? (operator/bot available)
→ Result: Show button only if BOTH are true
Implementing the visibility logic
The chat button is linked to the targeting and conversation workflow and should update its visibility each time the status of those workflows is changed. First of all you need to implement the appropriate callbacks:
The chat button gives access to the Chatbox so it should be visible:
at all times when a conversation is ongoing to allow the visitor to come back to the current conversation
when the active targeting rule is available, to engage the visitor to chat
3️⃣ Opening the Chatbox
When the visitor taps on your custom chat button you should open the Chatbox by calling the following method:
⌨️ In-context example: Full custom chat button implementation
⌨️ In-context example: Full custom chat button implementation
You can be informed of the Chatbox opening/closing by subscribing to the right listener:
🔔 Handling push notifications
Before starting this part you will need to configure push notifications inside your application. You can refer to the following resources if needed:
You will also need to ensure that the push notifications are setup in your iAdvize project. The process is described in the Mobile SDK Knowledge Base.
1️⃣ Registering the device token
For the Mobile SDK to be able to send notifications to the visitor’s device, its unique device push token must be registered:
⌨️ In-context example: Device token register
⌨️ In-context example: Device token register
The ApplicationMode is used only for the iOS application.
The ApplicationMode is used only for the iOS application.
2️⃣ Enabling/disabling push notifications
Push notifications are activated during Mobile SDK activation, as long as you have setup the push notifications information for your app on the iAdvize administration website (process is described in the SDK Knowledge Base). You can manually enable/disable them at any time using:
3️⃣ Handling push notifications reception
Once setup, you will receive push notifications when the operator sends any message. As the SDK notifications are caught in the same place than your app other notifications, you first have to distinguish if the received notification comes from iAdvize or not.
Notifications will be received in your app for all messages sent by the agent. It is your responsibility to display the notification and to check whether or not it is relevant to display it. For instance, you don’t need to show a notification to the visitor when the Chatbox is opened
4️⃣ Customizing/localizing the notification
You are responsible for displaying the notification so you can use any title / text / icon you want. The text sent by the agent is available in the content part of the notification data received.
⌨️ In-context example: Handling received notification
Our SDK uses APNs localization keys so iOS fetches the translated title from your app’s localization resources.
Key used by the SDK
iadvize_notification_title— shown when a new message arrivesRecommended English value: “You have received a new message”
What you need to do
Add the key to your app’s localization files
Use a String Catalog (
Localizable.xcstrings) or a classicLocalizable.strings.Ensure the resource is included in your app target.
Provide translations for every language your app supports
English
French
Why this is required
When APNs payloads use title-loc-key, iOS resolves the key only against the app’s main bundle. Even though the SDK ships its own translations, notification title must exist in your app bundle so the system can find it. If a translation is missing for a given locale, iOS will fall back using your app’s standard localization rules (e.g., your development region).
Translation suggestions
Here are translations you can use if your app supports some of these languages.
cs
Czech
Dostali jste novou zprávu
da
Danish
Du har modtaget en ny besked
de
German
Sie haben eine neue Nachricht erhalten
en
English
You have received a new message
es
Spanish
Has recibido un nuevo mensaje
fr
French
Vous avez reçu un nouveau message
it
Italian
Hai ricevuto un nuovo messaggio
lt
Lithuanian
Jūs gavote naują žinutę
nl
Dutch
U hebt een nieuw bericht ontvangen
pl
Polish
Otrzymałeś nową wiadomość
pt
Portuguese
Recebeu uma nova mensagem
sk
Slovak
Dostali ste novú správu
sv
Swedish
Du har fått ett nytt meddelande
5️⃣ Clearing push notifications
The iAdvize Mobile SDK notifications are automatically cleared from the Notification Tray / Notification Center when the Chatbox is opened. If you want to clear them at any other given time you can call this API:
However, as notifications display depends on the Notification Channel, some configuration is needed in order for this behavior to work correctly:
First of all create the Notification Channel:
Then, when receiving the notification, send it through the SDK Notification Channel if the notification is from iAdvize:
On iOS no setup is required, the clearing of the push notificatiosn works out of the box.
First of all create the Notification Channel:
You don't need to check that you are on the Android platform before calling this API, as it does nothing on the iOS platform.
Then, when receiving the notification, send it through the SDK Notification Channel if the notification is from iAdvize. In order to show a notification in a specific Notification Channel, please refer to your Notification library documentation.
First of all create the Notification Channel:
You don't need to check that you are on the Android platform before calling this API, as it does nothing on the iOS platform.
Then, when receiving the notification, send it through the SDK Notification Channel if the notification is from iAdvize. In order to show a notification in a specific Notification Channel, please refer to your Notification library documentation.
📈 Adding value to the conversation
1️⃣ Registering visitor transactions
You can register a transaction made within your application:
2️⃣ Saving visitor custom data
How custom data is used
Custom data you register:
Operators: See values in "Custom data" sidebar tab
Workflows/AI Shopping Assistant: Use values as context parameters (e.g.,
productIdto fetch product info)Visitors: Don't see raw values in chatbox
See Using custom data with workflows & AI Shopping Assistant for examples.
Example
The iAdvize Mobile SDK allows you to save data related to the visitor conversation:
As those data are related to the conversation they cannot be sent if there is no ongoing conversation. Custom data registered before the start of a conversation are stored and the Mobile SDK automatically tries to send them when the conversation starts.
The visitor data you registered are displayed in the iAdvize Operator Desk in the conversation sidebar, in a tab labelled Custom data:

3️⃣ Using custom data with workflows & AI Shopping Assistant
Custom data you register is:
✅ Visible to operators - Displayed in "Custom data" tab in operator desk
✅ Usable by workflows/AI Shopping Assistant - Passed as contextual parameters to retrieve information
❌ Not shown to visitors - Raw values don't appear in chatbox
How workflows and/or AI Shopping Assistant use custom data
The AI Shopping Assistant and workflows can use custom data (like productId) as context to retrieve relevant information from your configured knowledge sources.
Example: Product Context on PDP
When a conversation starts:
The operator sees: productId = SKU-12345, productName = Garden Hose 50ft
The AI Shopping Assistant uses productId to query your product catalog (if configured in knowledge sources)
The bot can answer product-specific questions without the visitor repeating information
Important: The bot doesn't display raw custom data values to visitors. It uses them as lookup parameters to retrieve relevant information from your configured knowledge sources.
Channel-agnostic workflows/AI Shopping Assistant behavior
Workflows/AI Shopping Assistant configuration in iAdvize Admin works identically across:
Web
Mobile App (Mobile SDK)
Social/Messaging channels
The Mobile SDK provides the conversation interface; the workflows/AI Shopping Assistant intelligence and behavior are configured in iAdvize Admin and remain consistent across all channels.
Use cases
Product pages: pass productId for product-specific assistance
Cart: pass cart contents for contextual recommendations
Order tracking: pass orderId for WISMO (Where Is My Order) workflows
Category pages: pass category info for relevant suggestions
Learn more about AI Shopping Assistant configuration: documentation
👍 Fetching visitor satisfaction
The satisfaction survey is automatically sent to the visitor at the end of the conversation, as long as it is activated in the iAdvize administration website. The survey is presented to the visitor in a conversational approach, directly into the Chatbox.

📊 Analytics & Monitoring
iAdvize Admin dashboard
Filter mobile conversations in Reports:
By targeting rule: Name rules clearly ("Mobile - Homepage", "Mobile - PDP")
By routing rule: Track performance per team/bot
Standard metrics: Conversations, response time, CSAT, NPS
Limitation: Cannot differentiate iOS vs Android (both show as "Mobile App" channel)
Advanced Analytics: GraphQL API
For detailed metrics and historical analysis:
TARGETING_RULE_DISPLAY_NUMBER- How often chat button was displayedTARGETING_RULE_TRIGGERED- How often conversations startedPre-aggregated indicators for periodic exports
Documentation: Retrieve Messages & Pre-aggregated Indicators
⚠️ Note: These are historical/reporting metrics, not available in real-time for app logic.
App-side analytics
The Mobile SDK does NOT track or report:
When/why you call
activateTargetingRule()User behavior that leads to trigger activation
Frequency of button displays per visitor
Session tracking and user preferences
You must instrument these in your analytics platform (Google Analytics, Firebase, Mixpanel, etc.) for:
Trigger effectiveness analysis
A/B testing trigger strategies
User engagement patterns
Conversion funnel tracking
Last updated