Use HTML element to determine audience for experience targeting | Community
Skip to main content
R
Roxie423
Level 2
January 21, 2021
Solved

Use HTML element to determine audience for experience targeting

  • January 21, 2021
  • 1 reply
  • 3683 views

Dear all,

 

We have a website where the search terms are obtained from the HTML elements when the the website is redirected to the result page.

We want to use this information in AT to determine the audience for experience targeting. 

 

In specific, the user search for the depart and return date/location for their travel.

The result page following this only shows the first part of a two-way travel or the one-way travel alone.

The depart date, depart location, arrive location are used to determine if the user falls into the audience for certain information to be shown on the same result page, preferably without having to reload.

And the next page shows the return trip, with the depart date, depart location, arrive location again used to determine if the user falls into the audience for certain information to be shown on the same result page, preferably without having to reload.

 

I wonder if the timing works out, as the info could only be taken from the HTML elements.

 

In addition, for a two-way travel, the first and second parts have the same URL with only the random parameter changed. 

This probably makes the implementation even more difficult I suppose?

 

I would really appreciate it if anyone has any idea on this.

 

Thanks in advance.

 

Roxie

    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 josejr19

    @roxie423 There is a few ways of doing this I will outline the option I think you are seeking, and some alternatives I would recommend.

     

    1. HTML Element Scrapping(What you mentioned)-  For this option we are running a script prior to calling Target to grab the value from the css selector that holds the value and then passing it to target as a parameter. My biggest concern here is if the value is present in the DOM/HTML before calling Target. If its not then the global mbox Target call wont catch it and you will have a race issue where Target is called prior to having the value in the DOM/HTML which will force you to find a way to get this value in the DOM before Target or make a second call to Target using the getOffer/applyOffer function. You will need to pass in the additional parameter into Target using the targetPageParams() function. So you will need to add functionality for both scrapping the HTML element value and then also passing it to the Target at.js library before calling the global mbox. Example of this function below. Lastly you create an audience saying the parameter name you passed in the targetPageParams needs to equal XYZ value to qualify for the experience.

     

    function targetPageParams() { 
    return "param1=value1&param2=value2&p3=hello%20world"; 
}

     

    2. Functional Data Layer - For this option, we set the value the user is inputting into the sessionStorage or localStorage every time they search but prior to hitting the submit button on the request to see the results page. By doing this you have the values set to go as soon as the results page starts to load and now you can pick it up with the global mbox Target call. This eliminates the race issue as long as you set the value in the sessionStorage or localStorage prior to going to the results page. In terms of managing it, similar to #1 you need to pass in additional parameters to the Target at.js library before calling the global mbox. Example of this function shown in option #1. Lastly you create an audience saying the parameter name you passed in the targetPageParams needs to equal XYZ value to qualify for the experience.

     

     

    3. URL Parameters - For this option, we pass in the results page the data we need as URL query parameters. i.e "www.airline.com/results?departAP=EWR&returnAP=MIA". If you have this in place it might be your easiest route to go with because you are already passing this information to the global mbox Target call out of the box. Thats because the at.js script already passes in the url the visitor is on and any url query parameters on each global mbox call. So then the only thing you need to do is create an audience based on the site pages < current page < query < contains "departAP=EWR" if you want to show an experience to this airport code. This is going to be your easiest list if you have these values on the results page in the URL bar. If you dont then it will need to be implemented.

     

     

     

    Hope this helps and addresses your question!

     

     

    1 reply

    J
    josejr19Accepted solution
    Level 5
    January 21, 2021

    @roxie423 There is a few ways of doing this I will outline the option I think you are seeking, and some alternatives I would recommend.

     

    1. HTML Element Scrapping(What you mentioned)-  For this option we are running a script prior to calling Target to grab the value from the css selector that holds the value and then passing it to target as a parameter. My biggest concern here is if the value is present in the DOM/HTML before calling Target. If its not then the global mbox Target call wont catch it and you will have a race issue where Target is called prior to having the value in the DOM/HTML which will force you to find a way to get this value in the DOM before Target or make a second call to Target using the getOffer/applyOffer function. You will need to pass in the additional parameter into Target using the targetPageParams() function. So you will need to add functionality for both scrapping the HTML element value and then also passing it to the Target at.js library before calling the global mbox. Example of this function below. Lastly you create an audience saying the parameter name you passed in the targetPageParams needs to equal XYZ value to qualify for the experience.

     

    function targetPageParams() { 
    return "param1=value1&param2=value2&p3=hello%20world"; 
}

     

    2. Functional Data Layer - For this option, we set the value the user is inputting into the sessionStorage or localStorage every time they search but prior to hitting the submit button on the request to see the results page. By doing this you have the values set to go as soon as the results page starts to load and now you can pick it up with the global mbox Target call. This eliminates the race issue as long as you set the value in the sessionStorage or localStorage prior to going to the results page. In terms of managing it, similar to #1 you need to pass in additional parameters to the Target at.js library before calling the global mbox. Example of this function shown in option #1. Lastly you create an audience saying the parameter name you passed in the targetPageParams needs to equal XYZ value to qualify for the experience.

     

     

    3. URL Parameters - For this option, we pass in the results page the data we need as URL query parameters. i.e "www.airline.com/results?departAP=EWR&returnAP=MIA". If you have this in place it might be your easiest route to go with because you are already passing this information to the global mbox Target call out of the box. Thats because the at.js script already passes in the url the visitor is on and any url query parameters on each global mbox call. So then the only thing you need to do is create an audience based on the site pages < current page < query < contains "departAP=EWR" if you want to show an experience to this airport code. This is going to be your easiest list if you have these values on the results page in the URL bar. If you dont then it will need to be implemented.

     

     

     

    Hope this helps and addresses your question!

     

     

      R
      Roxie423Author
      Level 2
      January 22, 2021
      @josejr19 Thanks for the reply, I will look into sending an additional mbox for reporting, have a nice day!
      Terms & ConditionsAccessibility statement

      Loading footer...