How often does Monetate send data to a third-party platform?
Monetate pushes experience data on the first trackData()
call after experience qualification and on the track that occurs every 5 minutes thereafter.
For example, a visitor lands on a page, and then Monetate sends the reporting information for the active experiences to your third-party platform. It doesn't send information to the third-party platform again until either a track occurs when a site visitor enters a new experience, or a track occurs 5 minutes or more after the last time Monetate sent data to the third-party platform.
Does Monetate aggregate the data that it sends to a third-party platform?
The data isn't aggregated. Monetate sends data on every page load.
What impact do stealth groups have on the data that Monetate reports to a third-party platform?
Stealth groups prevent internal users from impacting the experience data provided natively in Monetate. However, stealth groups do not prevent internal users from impacting the experience data on other platforms. Contact your third-party platform provider for more information.
Why don't I see data in my third-party platform for a Full-Page Test experience?
You can't report third-party analytics for Full-Page Test experiences due to timing constraints. Monetate's third-party analytics report attempts to fire on the initial page but can't complete the action due to the redirect.
Can I track Monetate events in my third-party analytics?
Currently, the platform's third-party analytics are only configured to potentially pass the event label for session count statistics. Monetate has only the following variables available within the campaign object:
id
— The unique ID of the experience (for example,217022
)key
— A shortened version of the experience name appended with the experience ID (for example,A/B-Test_217022
)split
— The split name (for example,Experiment
orA-control
)
If you're making custom trackEvent
calls with the API, you can configure them to also make a call to pass an event to your third-party analytics application.
Why can't I edit my third-party report after creating it?
Once a third-party analytics report is created and added to existing experiences, it can't be edited. If you want to edit the report, you must remove it from all existing experiences, whether they're active or inactive, and then apply the update. Submit a request for a list of experiences currently using the report using the Monetate Technical Support portal (support.monetate.com). Otherwise, you can create a new report and apply the updates in that new report.
How can I verify that a report is working?
If you need to test a custom report, you can do so from the report configuration page by adding the JavaScript console.log()
method to a report code. After you add the console.log()
method, click the preview icon to load your site in Preview Mode in a new browser tab or window. Launch your browser's developer tools, and then switch to its console to confirm that the message you encoded as part of the console.log()
method appears.
For an example of how to use the JavaScript console.log()
method to test a report, see Testing the Report in Configure a Custom Third-Party Analytics Report.
If you need to test a Contentsquare integration, use the Contentsquare Tracking Setup Assistant. Follow the steps in Testing the Integration of the Contentsquare integration documentation.
If you need to test a Google Analytics integration that you created using Monetate's default code, launch the Monetate Inspector browser plug-in, and then navigate to the Actions tab on the Components. There you can find any reporting labels submitted. The Reporting labels appear last in the list of actions with sr2
or Submit Reporting Events
in the Name column.
Note that reporting labels fire on the first page view for a given experience as well as every 5 minutes (on the next page load), or any custom frequency you've requested from Support.
You can also find this information on the Network tab in many browsers' Developer tools feature or by using a browser extensions such as Omnibug to verify that the calls to your vendor are specifically firing with the expected data.
Additionally, you should see data flow into your analytics platform based on its data-processing timing.