Discover how to push A/B testing and personalization variables from Umbraco Engage to the Google Tag Manager (GTM) data layer in Razor templates.
Umbraco Engage provides a partial view that pushes variables related to A/B testing and personalization to the Google Tag Manager (GTM) data layer.
The following variables are pushed:
inabtest: true - if the visitor participates in an active A/B test on the page; otherwise false.
This will also be true if the visitor is assigned to the "A" variant which is the original page.
abtestname - The name of the A/B test the visitor is participating in. If there is no active A/B test, the value will be null
abtestvariant - The name of the A/B test variant assigned to the visitor. If there is no active A/B test, the value will be null
personalized: true - If personalization is applied to the page for the visitor; otherwise false.
personalizationname - The name of the active personalization. If there is no active personalization, the value will be null.
To render the partial view in your Razor template, use the following line:
This partial will render the following output:
Discover how to enhance the accuracy of your Umbraco Engage Analytics by replacing specific extractors to collect additional or more accurate data.
Data collection is essential to the Umbraco Engage Analytics feature. When a visitor requests a page on your website, the web request is analyzed for relevant information, which is then stored in the database.
However, there may be times when the data collected is not entirely accurate, or you might have additional data to complement the Umbraco Engage dataset. In the following articles, we will explain how to replace specific extractors that obtain particular pieces of information from a request.
Learn how to extract client IP addresses in Umbraco Engage by implementing a custom IP address extractor for specific server environments.
By default, Umbraco Engage extracts the IP address from the request by inspecting the UserHostAddress and the X-Forwarded-For header. The latter is commonly used if your website operates behind a load balancer. In most scenarios, this will correctly resolve the client's IP address.
If IP addresses are not being resolved accurately, your website may be behind a load-balancing server or another protected environment. It might not forward the original client IP in the default X-Forwarded-For header or could exclude it entirely.
In this case, you may need to provide a custom implementation of the IHttpContextIpAddressExtractor to handle your specific requirements.
The default extractor looks like this:
To override this behavior, implement your own IHttpContextIpAddressExtractor and instruct Umbraco to use your extractor instead of the default extractor:
It is important that your UserComposer adjusts the service registration after Umbraco Engage has initialized.
This can be enforced using the ComposeAfterAttribute. Failing to add this attribute may result in Umbraco running your IUserComposer before the Umbraco Engage composer, causing your changes to be overwritten.
Additionally, ensure you use RegisterUnique<...>() instead of Register<...>(). While you can use Register when multiple implementations of a single service exist, in this case, you want your own extractor to be resolved exclusively. Therefore, RegisterUnique will overwrite the Umbraco Engage extractor.
After implementing both classes and running your project, your extractor should be called to resolve IP addresses. You can verify the output of your extractor by inspecting the umbracoEngageAnalyticsIpAddress database table. The last portion of the IP address may be anonymized (set to 0) if this option is enabled in the Umbraco Engage configuration file.