In-app content blocks

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 too intrusive. They are adapted to be used also in-table in 2 formats:

• Static content blocks
• Carousels

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

Use case examples

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

Content block types

Static content blocks

Static content blocks help you deliver a single message that does not change. This content block is ideal for critical announcements or permanent offers within the app.

Carousels

Carousels enable the rotation of various messages within a single block. Carousels are perfect for displaying multiple offers or messages without the need for extra screen space.

Specify the type of content block (static or carousel) when setting up the SDK. For carousels, create a new UI component, CarouselInAppContentBlockView.

For detailed developer settings, refer to Android or iOS SDK setup.

Setup guide

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. The management of in-app content blocks is handled through the Bloomreach Engagement app. Review our documentation on how to set up the mobile SDKs:

• Android
• iOS

Create a template

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

Templates marked as Native are only available as In-app messages, not In-app content blocks.

All other templates or a blank template can be displayed in the Visual Builder (default) or HTML Builder.

Visual Builder

The Visual Builder allows you to use a drag-and-drop editor. You can create and modify your own templates.

HTML Builder

The HTML Builder allows you to customize the HTML of your in-app messages and in-app content blocks. Test your HTML code on a real device before launching your campaign to ensure compatibility across different devices. This step helps identify and resolve potential issues, ensuring a seamless user experience.

Standard HTML and CSS use

Always use standard HTML and CSS. 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

Choose personalization type

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).

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.

Placeholder ID

This is the ID of the placeholder in which you want the campaign to be shown. You can insert multiple IDs if you want the campaign to be shown in different placeholders

The placeholder ID is tracked as an event property. If you are using this property further, for example, for campaign analytics, 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 the higher priority will be shown. If they have the same priority, one will be selected at random.

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 remains there. This is because 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 open a browser and come back to the app, the placeholder shows 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.

Fetch in-app content blocks

You can optionally specify a list of placeholders to be fetched in advance when initializing the SDK. This ensures they are ready to be displayed when needed.

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 to get the latest updates. For example, something that may change based on your in-session behavior. For more information, review Mobile SDK documentation.

Tracking

Each in-app message shown to a customer is tracked as a banner event with the same attributes as in any weblayer. Additionally, the following attributes unique to in-app personalizations are tracked:

Error messages

If an error occurs while delivering an in-app message to a customer's device, the banner event will have an additional attribute error with an error message as value.

You may encounter the following error messages:

If any of the above errors are tracked frequently, that may indicate e a problem with the implementation of the Mobile SDK in your app.

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.

Tracking

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 (for example, 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.

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.