Weblayer reference

This guide covers advanced weblayer topics, including manual SDK triggering, generated events, adding recommendations, lag handling, and troubleshooting.

Manual trigger via SDK

In addition to automatic triggering based on weblayer settings, you can trigger a weblayer manually using the SDK function exponea.showWebLayer(). This is useful when you want to trigger a weblayer based on a button click or viewed product attributes.

When using showWebLayer(), only the Audience and Display settings apply.

Call the function using custom JavaScript — for example, through Tag Manager or another weblayer. Note that it's not possible to trigger a weblayer using backend events.

For more information, see SDK personalization.

Events generated by weblayers

Weblayers generate banner events when interacted with. These events are defined and tracked in the JavaScript code of each weblayer and are enabled by default.

The banner event has the following attributes:

• action — show, click, or close
• banner_id
• banner_name
• banner_type
• variant_id
• variant_name
• interaction
• campaign_id (applies to weblayers in scenarios)

Some weblayer types track additional actions:

• Subscription banners: Track action=subscribe on subscription, including form inputs as attributes (email, first_name, last_name, birthday).
  Note: The email property is tracked as an attribute of the banner event — not as a customer property. To save the email address as a customer property, create a scenario to track it separately.
• Web push subscription banners: Track action=subscribe on subscription.

Add recommendations using Jinja catalog lookup

To use a recommendation engine, a catalog is required. The engine returns a list of item_id values. Use catalog lookup to render recommendations in the weblayer:

<ul id="recommendations">
  {% for item in recommendations['0102030405example'][:8] %}
  <li> <a href="{{ item.link_url }}">{{ item.title }}</a> </li>
  {% endfor %}
</ul>

• Replace 0102030405example with the actual recommendation ID.
• [:8] limits the output to 8 recommendations. Adjust this number to show more or fewer items.

Lag handling

The SDK includes session storage logic that prevents a weblayer from reappearing after a customer has already closed it, even if there's a delay in event processing. This protection applies to the Until interaction, Once, and Once per visit display settings.

Troubleshooting

Weblayer isn't visible after launch

There are a few possible reasons your weblayer isn't appearing.

1. A/B testing control group
If you're using A/B testing, you may have been assigned to the control group, which shows the original variant by default. To check, go to Customers and review the events tracked to your profile. You can also use the Bloomreach console Chrome extension to view events being tracked live in the console.

If this is the cause, either adjust your A/B test settings or open the page in an incognito window. Incognito mode assigns a new cookie each time, which may place you in a different variant.

2. Settings configuration
Check the following in your weblayer settings:

• Show on: Confirm the condition matches the page you're loading.
  • For Page URL containing or Page with URL options: Check that there are no spaces before, within, or after the text you entered.
• Category: If the campaign requires specific consent, your profile must have that consent to see it.
• Audience: If you added audience conditions, your profile must match them.

Weblayer only appeared once

If the Display control setting is set to Once only or Until interaction, the weblayer won't reappear after the first interaction. This is tracked via the banner event, so the weblayer recognises who has already seen it.

To see it again:

• Change the Display control setting to Always show or Once per visit.
• Open the page in an incognito window — incognito starts a fresh session with no interaction history, so the weblayer treats you as a new visitor.