Confirmation and Guidance Needed for Job Search Filter Tracking in Adobe Analytics

[priyankagupta20]

Dear Team,

I need to track the search filters, which have various options, and define a data layer structure for this.

Here’s the data layer suggestion we’re considering:

adobeDataLayer.push({
"event": "JobSearchFiltering",
"event_info": {
"searchTerm": "software development", // Value of the search term
"searchResultCount": "2", // Number of search results after applying filters
"searchFilters": "Berlin, Software Engineering, Professional" // User-selected search filters
}
});

For `searchFilters`, I’d like to confirm if this format is appropriate:
- Option 1: `"searchFilters": "Berlin, Software Engineering, Professional"`
- Option 2: `"searchFilters": ["Berlin", "Software Engineering", "Professional"]`

Could you advise which format is more suitable? or both are wrong?

Additionally, I want to capture the filter values in `List eVar1` in Adobe Analytics using Adobe clinet data layer. Could you guide me on setting this up? Thank you!

[Jennifer_Dungan]

While technically you could probably parse either one into a list variable.... it depends on if you want to do any other logic... if you just want to pass this into a list var, and the delimiter is comma, you can use Option 1... though I might ensure that there's no spaces (just in case):

"searchFilters": "Berlin,Software Engineering,Professional"

So you don't have to worry about whitespace in your data....

However, if you might try to add extra logic at a future date, having the data passed as a list will remove a lot of added complexities, as you will be able to read each value separately. It's still easy enough to pass the actual list to Adobe, simply by using a Join():

adobeDataLayer.event_info.searchFilters.join(",")

Personally, I would lean towards option 2... since that gives the greatest future flexibility...  but both would work... it comes down to what you are comfortable with, and where you may want to go with this in the future.

Good Luck!

[priyankagupta20]

Thank you very much for the detailed explanation!

I have one more question about the implementation.

Typically, I create a data element based on the data layer in Adobe Launch and then, within the "Set Variables" rule, I select the appropriate eVar and attach the data element (let's say the data element I created is called "jobFilters").

However, I noticed that list eVars don’t appear in the eVar dropdown.

Does this mean we can only use custom code for list eVars? If so, would the following code be correct for setting it:

s.list1 = _satellite.getVar("jobFilters");

Will this work as expected, or is there a different approach you’d recommend?

Thanks again for your guidance!

[igupta]

Hi @priyankagupta20 ,

Yes, you can only set a list variables through custom code and there is no dedicated field in the extension. Your code looks correct to me. You can validate by looking at the data element value in developer console on the page in question.

You can refer the help text on this page for more info.

https://experienceleague.adobe.com/en/docs/analytics/implementation/vars/page-vars/list

[bjoern__koth]

@priyankagupta20 when using custom code to capture list variable in link tracking, make sure to append the list vars to your s.linkTrackVars property.

s.linkTrackVars += ",list1" 

// if you have installed the "APL" (append to list) extension, you can do it like this
s.linkTrackVars = s.apl(s.linkTrackVars, "list1")

[Jennifer_Dungan]

Yes, I had the same problem in my implementation too...

Now, there is a caveat to setting the list manually... on the page view, there's no problem.. you can add the code into the custom code of the "Set Variables" action, and it will be included...

As others have said, if you are adding it to your Actions, you will need to manually append it into the s.LinkTrackVars (see @bjoern__koth's comment)

Still to this day, I do not understand why the list vars aren't directly available in the UI....

[bjoern__koth]

Hi @Jennifer_Dungan 

unfortunately, there is no adobeDataLayer.event_info property.

Instead, you would need to access it like this (assuming it is an array and the code is run in a data element)

// make sure to gracefully access the data using optional chaining ?.
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining
return (event?.message?.eventInfo?.searchFilters || []).join(",")

[Jennifer_Dungan]

That was a custom field as per the sample provided in the original ask...

Since they showed code pushing in this custom Key, I assume this is how their site is set up to work... not sticking to the "traditional" key value pairs...  

I was merely sticking to their own samples... but you are right, if they are trying to stick to traditional AdobeDataLayer tags, then they will need to push the information a different way.

Update: Oh I see what you mean... yes, because the AdobeDataLayer is an event based data layer, I was more promoting the "join()" function, than the actual targeting of the data...

Personally, I hate event based data layers, and rarely use them...  I use a custom data layer that is set on the page, but once set, it's set.. it's not updated with events so I can access it directly.

[BjörnKo1]

Yeah I got that it was like that in the first place ☺️

The ACDL takes a moment to sink in and is not perfect, but surely is a powerful tool. I also had my fair share of head scratches in the beginning

[Jennifer_Dungan]

It's not so much about "not understanding it"... it's more about, I don't like the all the extra execution of event based data layers...

Using a click event for example... why should I do the following steps:

1. Listen for the click
2. Update the Data Layer with info about the click
3. Listen for a change in the Data Layer
4. Track the click from the information in the Data Layer

Now, if your developers are doing ALL the data layer updates, that is one thing.,.. However, when it comes to that I have a long history of developers not triggering it correctly or at all, missing data, or just the general wait time for a developer to do the work.... 

If I am listening for the click myself, why on earth would I do all those added steps? When I know when and what was clicked, I can track the click immediately without all the extra steps..

And when you come down to it, with timing and efficiencies of the page unloading and loading the next one, the more steps you have in your process, the more risk you have of losing the tracking all together... Not using an event based data layer turns the above steps into:

1. Listen for the click
2. Track the click from the information

Less steps, less overall execution time, less change for the tracking to be lost completely... 

Hence, why I don't use it... it's one of the things I absolutely hate about GA/GTM which I also handle for my company....   (that and the ACDL didn't exist when we started using Launch for tracking our sites... and we made a conscious decision to not use it when it was released for the above reasons)

Even now, when I need a developer controlled action (like a success action), I don't use a Data Layer, I have them trigger a custom JS event, and include the relevant information in the detail property of the event.. and I read it directly....

[bjoern__koth]

Fully agree, an event driven approach is usually best with cooperative developers, which you may typically get when a website is redeveloped.

ok the other hand, a data layer approach can come in handy if additional contextual information must be passed in. Fair enough, one can argue that if a fronted developer has to develop it, this information must be part of the website's DOM or window scoped JS variables which you could pick up yourself

Anyway, I like the ACDL for the fact that it has its persisted state and that event information can be handled separately. 

Side note: if something in the website structure breaks, the devs have to fix it and not you when your CSS selector of your click event does not work anymore.

Bottom line: it really depends what approach is best I guess. There is no right or wrong. This may also be the reason why Launch leaves it up to you to decide

[bjoern__koth]

Hi @priyankagupta20 

the Adobe Client Data Layer does not support a "event_info" attribute, unless you want to persist this information in the data layer.

Instead, you will have to use "eventInfo" object.

adobeDataLayer.push({
    "event": "JobSearchFiltering",
    "eventInfo": {
        "searchTerm": "software development", // Value of the search term
        "searchResultCount": "2", // Number of search results after applying filters
        "searchFilters": "Berlin, Software Engineering, Professional" // User-selected search filters
    }
});

Your "event_info" would be stored in the computed state which will only be accessible for this specific event. This is surely not what you want.

You can validate this by executing

adobeDataLayer.getState()

whereas

Will not persist. The key here is that when you have a page and perform any kind of user interaction on the same page without navigating away, if the data layer data is persisted across tracking calls, it may pollute succeeding calls.

• call1 (menu interaction without navigation) sets attribute X which gets pulled into prop10
• call2 (some other interaction to track, potentially with navigation) sets attribute Y which gets pulled into prop11.
  Now, using persisted event_info data, you may end up sending prop10 with call2 as well

Maybe you find some additional insights in this cheat sheet.

Hope that makes it clearer

[Jagpreet_Singh_]

@priyankagupta20 Did you find the suggestion helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!

[priyankagupta20]

Thank you very much for your guidance.

Previously, the eVar was displaying a value, so it appeared to be working well. However, based on your suggestion, I asked the developer to update it from `event_info` to `eventInfo`. Since making this change, the eVar value is no longer being captured, despite several attempts today.

Could I kindly ask for your assistance with this? I’ve attached a screenshot below with details of my attempts. The Adobe Launch rule is firing, but the eVar value isn’t appearing.

Thank you once again for your support!

[bjoern__koth]

Hi @priyankagupta20 

can you add a screenshot how your headerFooterLinkName data element is set up?

the path should be

event.message.eventInfo.link_name

Another REALLY important thing when using getVar and the ACDL, send the event as second parameter!

meaning: _satellite.getVar("myVar", event);

On top of that, be aware that since the value is only valid during the execution of the event, you won't be able to make this call in the developer console. I'd suggest that if you want to do logging, you can add a custom code action 

_satellite.logger.info("some data", _satellite.getVar("myVar", event));

[priyankagupta20]

Thank you for your help so far!

Please find the attached screenshot.

I tried using `event.message.eventInfo.link_name`, but it still isn’t working.
Additionally, `_satellite.getVar("myVar", event);` is also returning undefined.

 Any guidance would be greatly appreciated!

[bjoern__koth · Accepted solution]

Ah, I see.

So, as explained earlier, the eventInfo is not part of the computed state. This is an issue I previously raised with the developer of the extension that there is no real way to use the extension to access eventInfo data.

instead, use a custom code block and do a (note the ?. construct which is called optional chaining and won't throw an error should this link_name not be set)

return event?.message?.eventInfo?.link_name;

You can also go without dedicated data element and instead use this when you're assigning the eVar in the Analytics action's input field for the value 

%event.message.eventInfo.link_name%

In this case, the ?. construct is not needed since Launch takes care of that the code doesn't fail should it not be set