In-app content blocks

In-app content blocks let you display campaigns inside your mobile app that blend with your existing design. Unlike in-app messages—which appear as overlays or pop-ups—content blocks render inline with your app's content. They add value without interrupting the user experience.

Content blocks are available in 2 formats:

• Static content blocks: Display a single, fixed message.
• Carousels: Rotate multiple messages within a single block.

How content blocks work

Setting up content blocks involves 2 steps—one for your developer, one for you:

1. Your developer defines placeholder IDs: The developer creates placeholder views in your mobile app code, each with a unique ID.
2. You configure campaigns: You use those same placeholder IDs when setting up campaigns in Bloomreach.

Once the placeholders are set up, your developer's involvement ends. You can manage all campaigns through Bloomreach.

Placeholder behavior

When a placeholder has no active campaign assigned to it, one of two things happens—depending on how your developer configured it:

• Collapsed placeholder: The placeholder disappears and takes up no space when empty. It can also resize automatically based on content. This works for both static blocks and carousels.
• Fixed placeholder: The placeholder keeps its space even when empty, which may create blank areas in your app.

Your developer sets this behavior when they configure the placeholder.

When to use in-app content blocks

Content blocks are well suited for three common scenarios:

• Personalized content: Target users with relevant offers based on their behavior, or show product recommendations while they browse.
• Promotions and testing: Display special offers to specific user groups and A/B test different messages.
• Onboarding: Help new users discover features and surface helpful tips at the right moments.

Build content blocks

Static content blocks

Static blocks display one message that doesn't change. They work well for important announcements or permanent offers.

Carousels

Carousels rotate multiple messages in a single block—useful for showcasing several offers without taking up extra screen space. Each carousel item is a separate campaign and can redirect to a different URL.

When setting up the SDK, specify whether you want static blocks or carousels. For carousels, create a UI component called CarouselInAppContentBlockView.

For developer setup details, refer to Android or iOS SDK documentation.

Create a content block campaign

Choose a template

Ggo to Campaigns > In-app personalization to browse available templates or start from a blank template.

🚧

Important

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

All other templates—and blank templates—can be built using either the visual builder or the HTML builder.

The visual builder uses a drag-and-drop editor. You can create and edit templates without writing code.

The HTML builder lets you write custom HTML for your content blocks. Always test your HTML on real devices before launching to confirm it works across device types.

Follow these HTML rules:

• Use standard HTML and CSS only. Don't use experimental features.
• Don't use the following HTML tags: head, script, link, iframe, meta, title, and body.
• Don't use these attributes: onclick, href, or any other inline JavaScript attributes.

Select the personalization type

After choosing your builder, select the type of in-app personalization you want to create. The default is In-app message —switch to In-app content block using the dropdown on the left.

Configure settings

Fill in the campaign settings. Content blocks have one extra field compared to in-app messages—Placeholder ID. Enter the exact placeholder ID your developer created in the mobile app. You can add multiple IDs if you want the campaign to appear in more than one placeholder.

Name your placeholder IDs descriptively rather than using random characters. The system tracks placeholder IDs as event properties, so clear names help with analytics..

Make content blocks clickable

To redirect users when they interact with a content block, add buttons or action buttons to your design and configure them with one of the following:

• Hyperlinks: Open web URLs in the browser.
• Deeplinks: Direct users to specific screens in your app or another app.

This approach ensures proper tracking and smooth navigation.

Handle multiple content blocks

When you switch from an in-app message template to an in-app content block, the Close button (X) remains in the template. Here's what this means in practice:

Remove close buttons

When you switch from an in-app message template to an in-app content block, the Close button (X) stays in the template. Here's what happens:

• The close button appears in your content block.
• When users tap it, a close event is tracked — but the content block stays visible.
• If the content block is set to show until interaction, tapping the close button prevents it from appearing again.

📘

Note

Remove close buttons from content block templates. Users can't actually close content blocks, so the button has no functional purpose.

CSS images and custom fonts from recent SDK versions are supported.

Load content blocks

You can configure the SDK to fetch specific placeholders on startup, so they're ready to display when needed. You can also fetch content for a single placeholder at any point while the SDK is running — for example, to reflect changes based on what a user does during their session.

For setup details, see the Mobile SDK documentation.

Track events and data

Each content block shown to a customer is tracked as a banner event with the same attributes as any weblayer, plus these mobile-specific properties:

In-app content blocks generate events consistent with banners and weblayers, keeping your analytics aligned across all channels.

Error messages

If an error occurs while delivering a content block, the banner event includes an additional error attribute with a description of the issue.

If you see these errors frequently, there may be a problem with how the Mobile SDK is set up in your app.

Best practices

Images

Use image formats supported by your target platform:

• GIF, JPEG, and PNG are natively supported on both Android and iOS.
• WebP and HEIC are newer formats not supported on all Android and iOS versions.

Keep image sizes appropriate for your content block:

• Don't use images larger than necessary. Large images slow down delivery and increase bandwidth usage.
• Match image dimensions to your content block design. Mismatched dimensions are scaled down automatically but still waste bandwidth.

Screen resolutions

Some common screen resolutions to design for:

• 1284×2778: High-end iOS devices such as the iPhone 14 Pro Max.
• 1440×3200: Premium Android devices such as the Samsung Galaxy S series.

The Mobile SDKs track device and OS information. Use this data to understand the devices your users are on.

Limitations

Links in buttons

To add a data-link attribute—required for links to work in the SDK—the button or link must have a URL filled in. Without a URL, the editor won't generate an <a> tag and the data-link attribute will be missing. You need to fill in both the URL and the data-link attribute with the same value.

Performance

When using personalized content blocks that reference customer profile or catalog data, preload fewer than 10 content blocks and load additional ones on demand.

Follow these limits for best performance:

• Use fewer than 10 content blocks per placeholder.
• Don't show the same content block more than once every 5 seconds on a single device.
• Keep each content block under 100kB.

Tracking without consent

If a user hasn't granted tracking consent, their interactions with content blocks can't be tracked. The SDK stores display information locally on the device instead. This means:

• Content blocks still follow their display rules — for example, "show once" or "until interaction."
• If the local data is cleared, the content block may show again.

This can happen when IdentifyCustomer or Anonymize functions are called, if events aren't sent fast enough, or if there are rapid track and identifyCustomer calls in quick succession.

For detailed setup instructions, check our Mobile SDK documentation.