Use HTML element to determine audience for experience targeting

[#1]

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

[Roxie423 · Accepted solution]

@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!

[Roxie423 · Accepted solution]

@josejr19

Thank you for your prompt reply. 

Regarding option 1, it is likely that the HTML element we want to grab won't be available until the page so it would be difficult to use the targetPageParams() function.

Regarding option 3, the page url does not contain the necessary parameters and the referrer policy is strict-origin-when-cross-origin, making it impossible for AT to reference as well. 

I am not sure if option 2 would work and will look into that. Thank you very much.

As an alternative, we were thinking of using the Form-based activity to compare the relevant HTML element with variables containing the depart date, depart location, return location info previously defined in the same script. Do you think this is feasible?

Thank you very much!

Best,

Roxie

[josejr19 · Accepted solution]

Hey I dont see a response...

[Roxie423 · Accepted solution]

@josejr19 I have edited my comment sorry for the confusion

[josejr19 · Accepted solution]

Yes, I believe you are speaking of going down the parent/child activity route where you introduce js code via a VEC activity targeting everyone that hits the specific URL. This js code then grabs the value and triggers a getOffer/applyOffer call and passes in the HTML elements as parameters. Is this what you are saying? If so then this is an option as well but requires an addition call so on this specific URL you will have now have 2 calls on every page load.

[josejr19 · Accepted solution]

Perhaps for this specific URL you can disable auto global mbox and fire the getOffer/applyOffer function only when you have the HTML elements in place.

[Roxie423 · Accepted solution]

@josejr19 Thank you for the reply. We plan to apply the js code as an offer to everybody who hits the url, and that js code will look for certain HTML elements, compare their values with some predefined desirable values, and only when they equal a certain part of the webpage is then replaced by some other contents. Hence I believe no additional call would be required as we don't want to refresh that page. Do you think this is viable? Thanks in advance.

[josejr19 · Accepted solution]

That makes sense but then your metrics will show high impressions and unless you have something else tracking what offer was actually displayed your analytics will all be bunched up. I would recommend that if you are going to go this route that you still create the "child activity" but only use it for reporting, each experience in the child should have its own mbox name so that you can fire adobe.target.sendNotifications(options) function with the mbox name for reporting purposes if you are using Adobe Target as the reporting source. This is essentially still another call but its related to reporting and not fetching an offer.

[josejr19 · Accepted solution]

You can also use "adobe.target.getOffers(options)" available with at.js 2.x. Create separate experiences for each of the offers, fetch them all and then only fire the adobe.target.sendNotifications(options) function when you figure out in your code within the page which offer to show.

[Roxie423 · Accepted solution]

@josejr19 Thanks for the reply, I will look into sending an additional mbox for reporting, have a nice day!

[josejr19 · Accepted solution]

Sounds good!