In-app content blocks provide a way to display campaigns within your mobile applications that seamlessly blend with the overall app design. Unlike in-app messages that appear as overlays or pop-ups demanding immediate attention, in-app content blocks are shown in line with the app's existing content. They enrich the user experience without being overly intrusive. They are adapted to be used also in-table.

You have the flexibility to strategically position placeholders for in-app content blocks within your mobile app. Once set up, there is no further need for development involvement.

Setup Guide

To begin with, a mobile app developer needs to create placeholder UI views in the mobile app where the in-app content blocks will be displayed. Once these placeholders are established, the technical setup is complete, and the management of in-app content blocks is handled entirely through the Bloomreach Engagement app. Documentation on how to set up the mobile SDKs can be found here:

• Android
• iOS

1. Create a Template

To find different templates or a blank template, go to the section In-app personalization, under Campaigns.

Please note, templates marked as Native are currently only available as In-app messages, not In-app content blocks.

All the other templates or a blank template can be displayed in Visual Builder (default) or HTML Builder (available when you click on the tree dots in the top right corner of each template).

Visual Builder allows you to use a drag-and-drop editor, so even without coding skills you will be able to easily create and modify your own templates.

HTML Builder is designed for more technical users, who like to have the freedom to customize their HTML.

❗️

Test your HTML code on a real device to ensure it will work across devices before starting your campaign.

🚧

Use of Standard HTML and CSS

Always use standard HTML and CSS and avoid using experimental features or proprietary values.

Forbidden HTML tags and attributes:

• Tags: head, script, link, iframe, meta, title, body
• Attributes: onclick, href, and other inline JavaScript attributes

2. Choose the Type of Personalization

Once you have chosen your preferred way of building your campaign, choose which type of In-app personalization you want to create - In-app message (default) or In-app content block (available in the drop-down menu on the left).

3. Fill the Settings

Once you choose the type of In-app personalization and modify it to your business needs, fill in the Settings.

Compared to the settings of In-app messages, a new field was added.

Note that the placeholder ID is tracked as an event property. If you are using this property further, for example for campaign analytics, it might be a good idea to name them according to some logical system rather than random alphanumeric characters.

📘

Multiple In-App Content Blocks

If you create multiple In-app content blocks with the same Placeholder ID, the one with a higher priority will be shown. If they have the same priority, one will be randomly selected.

Now, you can run your campaign.

Specifications

When you modify an In-app message (even a click into a template is counted as a modification due to the limitations set in the Bee free editor) and then switch to an In-app content block in that template, the Close button will remain there. This is due to the fact that the same templates for In-app messages and content blocks are used.

If you leave it there, it will be displayed in the actual content block in the mobile application. When customers click on it, an event with action = close will be recorded, but the actual content block will not disappear from the app.

However, if the content block was set until interaction, the next time the placeholder is shown, this content block will not be displayed.

If the In-app content block is set until interaction and customers interact with it, then for example open a browser and come back to the app, the placeholder will show a different content block or none (if no other was set).

The CSS images and custom fonts from the SDK versions above are also supported.

Fetching In-App Content Blocks

You have the option (but it is not required) to specify a list of placeholders that can be fetched in advance when initializing the SDK (which means they will be ready to be shown when necessary).

You also have the option (but it is not required) to fetch content for a single placeholder at any point while the SDK is running, in order to get the latest updates (for example, something that may change based on your in-session behavior). You can find further information on this topic in our Mobile SDK documentation.

Use Case Examples

• Share personalized content at key moments
• Target and test promotions
• Onboard new customers

Limitations

• Links in buttons
  To add a data-link attribute (which is required for links to work in our SDK) the button or link needs to have a URL filled. When the URL is not filled the editor will not generate <a> tag and the data-link attribute will be missing. This means that you need to fill in both the URL and the data-link attribute with the same value.

• When using personalized In-app content blocks (any information from customer profiles or from catalogs), preloading less than ten content blocks is recommended. For better performance, load as many as possible on demand.
• In-app content blocks targeted for one placeholder <10.
• For the best system performance, it is advised to not show a unique content block more frequently than once every 5 seconds on a single device.
• One content block should not be larger than 100kB.
• If consent for tracking is not granted by the user when consents are enabled, Bloomreach Engagement is unable to track their interactions. However, the SDK securely stores this information locally. As a result, the content block will be displayed according to the specified settings (such as once, once per visit, or until interaction). If the local database is cleared, either by calling the IndetifyCustomer or Anonymize functions, this stored information will be lost. In such cases, the message will be shown again based on its settings. This behavior may also occur if tracked events are not sent to the system in a timely manner (e.g., due to manual event flushing) or if there are rapid track and identifyCustomer calls. Rest assured, detailed instructions and support to ensure smooth operation in our Mobile SDK documentation are available.

📘

Tracking

In-app content blocks generate events similar to banners and weblayers. This ensures consistency in tracking across different engagement mediums, allowing for comprehensive analytics and informed decision-making.