Check if the browser’s JavaScript console displays any errors. Unhandled errors could prevent the subsequent code from being executed properly. In case there are errors, check what script is causing the error and in what area. The path to the script might give an indication to what functionality the script belongs to.
In some cases, it might be helpful to add additional statements on component level. Since the component is rendered, you can add a temporary markup to show variable values which might help you indentify potential problems. For example:
<%
log.info("myVariable={}", myVariable);
%>
<!--
<%= myJspVariable %>
-->
<!--
${ myHtlVariable }
-->
For additional details about logging, see the Logging and Working with Audit Records and Log Files pages.
The Report Importer causes high CPU/Memory usage or causes OutOfMemoryError
exceptions.
To fix this issue you can try the following:
ManagedPollingImporter
configurations in the OSGi console.For additional details about creating custom data importer services in AEM, read the following article https://helpx.adobe.com/experience-manager/using/polling.html.
Analytics has been designed with an inheritance mechanism in mind. Usually, you enable Analytics for a site by adding a reference to an Analytics configuration within the page properties Cloud Services tab. The configuration is then inherited to all sub-pages automatically without the need to reference it again unless a page requires a different configuration. Adding a reference to a site also automatically creates several nodes (12 for AEM 6.3 and earlier or 6 for AEM 6.4) of the type cq;PollConfig
which instantiates PollingImporters used to import Analytics data into AEM. As a result:
Firstly, analyzing the error.log might give you some insight about the amount of active or registered PollingImporters. For example:
# Count PollingImporter entries
$ sed -n "s/.*(aem-analytics-integration-.*).*target=\(.*\),interval.*/\1/p" error.log | wc -l
86415
# Count PollingImporter entries for last30days
$ sed -n "s/.*(aem-analytics-integration-last30Days).*target=\(.*\),interval.*/\1/p" error.log | wc -l
14531
# Count unique paths of PollingImporter registrations
sed -n "s/.*(aem-analytics-integration-.*).*target=\(.*\)\/jcr:content.*/\1/p" error.log | sort | uniq -c
28115
Secondly, make sure that only top pages (high up in the hierarchy) have an Analytics configuration referenced.
For additional details about creating custom data importer services in AEM, read the following article https://helpx.adobe.com/experience-manager/using/polling.html.
The DTM script tag is not properly included in the page even though the configuration has been referenced in the page properties Cloud Services tab.
To fix the issue, you can try the following:
Make sure encrypted properties can be decrypted (note that encryption might use a different automatically generated key on each AEM instance). For additional details, also read Encryption Support for Configuration Properties.
Republish the configurations found in /etc/cloudservices/dynamictagmanagement
Check ACLs on /etc/cloudservices
. The ACLs should be:
For more information about managing ACLs, read the User Administration and Security page.
This issue happens because custom page components do not include the correct JSP or client libraries that handle the Target DTM integrations.
You can try the following solutions:
headlibs.jsp
(if any /apps/<CUSTOM-COMPONENTS-PATH>/headlibs.jsp
) includes the following:<%@include file="/libs/cq/cloudserviceconfigs/components/servicelibs/servicelibs.jsp" %>
<sly data-sly-resource="${'contexthub' @ resourceType='granite/contexthub/components/contexthub'}"/>
head.html
(if any /apps/<CUSTOM-COMPONENTS-PATH>/head.html
) does not selectively include specific integration headlibs like the example below:<!-- DO NOT MANUALLY INCLUDE SPECIFIC CLOUD SERVICE HEADLIBS LIKE THIS -->
<meta data-sly-include="/libs/cq/dtm/components/dynamictagmanagement/headlibs.jsp" data-sly-unwrap/>
The servicelibs.jsp
adds the required analytics JavaScript objects and loads the cloud service libraries associated with the web site. For Target service, the libraries are loaded via the /libs/cq/analytics/components/testandtarget/headlibs.jsp
The set of libraries that are loaded depend on the type of target client library ( mbox.js
or at.js
) used on the Target configuration.
When using DTM to deliver mbox.js
or at.js
make sure the libraries are loaded before the content is rendered. Using Tag Management Systems that load these libraries asynchronously could cause issues in executing the target specific JavaScript code.
For additional information, read the Developing for Targeted Content page.
This issue may appear when Adobe Analytics is implemented on the website by using DTM and uses Custom Code. The cause is using the s = new AppMeasurement()
to instantiate the s
object.
Use s_gi
instead of the new AppMeasurement
instantiation method. For example:
var s_account="INSERT-RSID-HERE"
var s=s_gi(s_account)
This issue can have multiple causes:
Loading Target client libraries ( mbox.js
or at.js
) asynchronously using 3rd-party Tag Management Systems may randomly break targeting. The Target libraries are supposed to be loaded synchronously in the page head. This is always true when the libraries are delivered from AEM.
Loading two Target client libraries ( at.js
) simultaneously, for example, one using DTM and one using the Target configuration in AEM. This can cause clashes for the adobe.target
definition if the at.js
versions differ.
You can try the following solutions:
Out of the box AEM 6.2 and 6.3 is not compatible with AT.js version 1.3.0+. With AT.js version 1.3.0 introducing parameter validation for its APIs, adobe.target.applyOffer()
requires an “mbox” parameter which is not provided by the atjs-itegration.js
code.
To solve this issue edit atjs-itegration.js
and add the "mbox": mboxName
field in the parameter object for adobe.target.applyOffer()
as follows:
adobe.target.getOffer({
"mbox": mboxName,
"params": params,
"success": function (response) {
adobe.target.applyOffer({
"mbox": mboxName, //<--- ADDED PARAM
"selector": "#" + mboxName,
"offer": response
})
},
This issue is most likely an A4T Analytics Cloud Configuration provisioning issue.
You need to verify that A4T is properly enabled for your Target account by issuing the following verification request to AEM:
http://localhost:4502/etc/cloudservices/testandtarget/<YOUR-CONFIG>/jcr:content.a4t.json
{
"a4tEnabled": true,
"sharedsecret": "SECRET",
"proxyUrl": "/libs/cq/contentinsight/content/proxy.reportingservices.json",
"active": "true",
"pageName": "",
"url": "https://api5.omniture.com/rs/0.5/",
"username": "USER@DOMAIN"
}
If the response contains the line a4tEnabled:false
, contanct Adobe Customer Care to get your account provisioned correctly.
Presented below are two Target APIs that might be useful when troubleshooting Target issues:
https://admin.testandtarget.omniture.com/rest/v1/endpoint/<CLIENTCODE>.json
{"api":"https://admin<N>.testandtarget.omniture.com/admin/rest/v1"}
https://admin<N>.testandtarget.omniture.com/admin/rest/v1/clients/<CLIENT>?email=<EMAIL>&password=<PASSWORD>
Response for N=4, CLIENT-dayintegrationintern
{
"clientCode": "dayintegrationintern",
"companyName": "Day Integration - Internal",
"omnitureCompanyId": "Day Integration Internal",
"softTraxId": -1,
"address1": "XYZ",
"city": "San Francisco",
"state": "ca",
"zip": "94107",
"country": "UNITED STATES",
"locale": "de_DE",
"timeZone": "Europe/Berlin",
"phone": "XX-XX-XXXX",
"serviceLevel": "Up to 100,000",
"privileges": [
"a4t",
"hosts",
"TnT-SC-integration",
"mvt",
"steps",
"testing-campaigns",
"view-snapshot",
"on-site-editor",
"optimizing-campaign",
"third-party-id-support",
"landing-page-campaigns",
"segment",
"rest-create-user",
"advanced-targeting",
"mobile-device-targeting",
"beta",
"geolocation"
]
}