Odd issues with profile parameters | Community
Skip to main content
jezwn
jezwn
Level 5
October 7, 2021
Solved

Odd issues with profile parameters

  • October 7, 2021
  • 3 replies
  • 2370 views

The context:

I have two user groups(beta1 and beta2) in AEM. When a user logs into the website, I capture whether they are in the beta1 or beta2 groups in a JS variable that is placed just before the launch script, so that when the delivery request is sent, I can utilize this value as a profile parameter for targeting. The following is the launch rule:

 

Where the custom code is:

 

 

function targetPageParams() { var group = userGroup; //userGroup variable is set to beta1/beta2 just before the launch script return "profile.userGroup="+group; }

 

 

 

The issue:

1. The profile parameters are not sent to the target on the very first page load. Target is giving the default experience since the request field for the profile parameters is empty. I tried replacing the custom code with a hardcoded value along but got the same result. The profile parameters are not being sent as anticipated when the user logs into the website for the first time/incognito.

Tried a console.log as well inside targetPageParams(). For the first page load after sign in, targetPageParams is not getting called but on a subsequent page reload the function is getting called and is consoling out.

 

 

function targetPageParams() { var group = userGroup; console.log(group); return "profile.userGroup="+group+"&profile.testGroup=test"; }

 

 

 

2. When I soft refresh(normal reload) the page (Ctrl+R), the profile parameters function as expected and the right experience is given, indicating that I just needed to reload the page once for the target to work. When I examine the delivery request after a hard reload (Ctrl+Shift+R), the profile params are missing, yet target is providing the right experience for the page(The response token does contains this value but no profile params are being send - Does this got anything with Experience Cloud Visitor ID and target is working based on that?). And I have to refresh the website multiple times to see the profile parameters in the delivery request, but the experience remains intact after each reload (normal or hard), indicating that the right experience is being delivered.

 

Both these issues appear to be strange and couldn't figure out why.

 

Update: I did try removing the custom code from the launch rule and placed it in the page header just before the launch script and that is working fine. The targetPageParams() is getting called every time irrespective of any cases and the right experience is being delivered. However, writing and updating the code in the page header doesn't appear to be a best practice as any additional change in params require a code change in AEM and a build.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Gaureshk_Kodag

Hi, 

Can u capture beta1/beta2 value in a data element and then before u fire target just add an action, "add params to all request". Inside that give name as profile.xyz = <data elem name>(in which u r capturing beta 1 beta 2 values)

3 replies

Gokul_Agiwal
Community Advisor
Gokul_AgiwalCommunity Advisor
Community Advisor
October 7, 2021

Hi @jezwn 

I know that in your setup Target library loaded through Launch and Launch embed codes linked with your page. 

 

Can you try one thing - define the targetPageParams() function before at.js loaded - I mean directly in your target interface - Look main navigation on top there you can see the option  

Administration -> Implementation -> On right hand side you can see at.js 2.6.1 ( latest version) -> Edit ->  Custom Library Header > Put the code here that needs to load before at.js. 

 

Hope this works for you. Thanks 

jezwn
jezwnAuthor
Level 5
October 7, 2021

Thanks @gokul_agiwal I couldn't get the custom library header to work for me. However, in Adobe Launch, I came across the 'Add Params to Page Load Request' action.

 

By definition it's equivalent to the targetPageParams() method as per Adobe docs:  Add Params to Page Load Request, which adds parameters to page load requests (equivalent to the targetPageParams() method). 

Reference: https://experienceleague.adobe.com/docs/launch-learn/implementing-in-websites-with-launch/implement-solutions/target.html?lang=en

 

This actually does the job and is working perfectly fine.

 

Where userGroup is the data element which captures the value from JS.

Gokul_Agiwal
Community Advisor
Gokul_AgiwalCommunity Advisor
Community Advisor
October 7, 2021

Hi @jezwn - 

I think you not have the full right to access administration section and that's why custom library header doesn't work for you. 

however this is correct Add Params to Page Load Request, is equivalent to the targetPageParams() method. 

 

Glad to know that your issues get resolved. Thanks.

    Gaureshk_Kodag
    Adobe Employee
    Gaureshk_KodagAdobe EmployeeAccepted solution
    Adobe Employee
    October 8, 2021

    Hi, 

    Can u capture beta1/beta2 value in a data element and then before u fire target just add an action, "add params to all request". Inside that give name as profile.xyz = <data elem name>(in which u r capturing beta 1 beta 2 values)

    Perrin_Ennen
    Community Advisor
    Perrin_EnnenCommunity Advisor
    Community Advisor
    October 12, 2021

    Hi @jezwn, sounds to me spontaneously like a timing issue..

     

    I don't know what exactly is the script that creates the UserGroup variable. Maybe you can write something like this as profileScript (as I said - I don't know the logic of the variable).

     

    But can't you just change the order in Launch:
    "Core - Custom Code" > "Adobe Target v2 - Load Target" > ..

     

    Maybe it also makes sense to write the script for the variable directly in the custom code:

     

    var userGroup = ... // script var targetPageParams = function () { var profile = {}; profile.userGroup = userGroup console.log("profile:", profile); return profile; };

     

     

    Terms & ConditionsAccessibility statement

    Loading footer...