Confused About entity.event.detailsOnly | Community
Skip to main content
Level 2
August 25, 2022
Solved

Confused About entity.event.detailsOnly

  • August 25, 2022
  • 1 reply
  • 1461 views

I was wondering if I can get some clarity on this entity attribute?

 

For whatever reason back in the day, we were firing two mbox calls on our product detail pages with the exact same entity attributes, but one call included entity.event.detailsOnly (set to true), and the other did not. The previous people that set up Launch and Target have moved on and I don't have context on why we had two nearly identical mbox calls on product detail pages.

 

I'm seeing if I can clean this up and only keep one of the mbox calls. But I'm wondering if I should keep entity.event.detailsOnly or remove it.

 

Here is what the documentation states:

 

In the examples below, the first mbox call updates the catalog and behavioral data. The second mbox call updates only the catalog.

mboxCreate('myMbox', 'profile.geo.city = new york', 'profile.geo.state = new york', 'entity.id = 123', 'entity.inventory = 4') mboxCreate('myMbox', 'profile.geo.city = new york', 'profile.geo.state = new york', 'entity.id = 123', 'entity.inventory = 4' 'entity.event.detailsOnly = true')

 

I'm not sure whether I should keep it and have it set to true, or remove it. Can somebody clarify this?

 

On a side note, for recommendation keys like "Current Item", does Target rely on a page having entity.id passed? And for "Current Category", is it looking for entity.categoryId?

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 cg8

Hi Nicholas,

 

I know this is 6 months late, but figured I'd answer your questions anyway.

 

detailsOnly is passed in situations where you want to call Target but do not want to record a "view" event. When a view event is recorded, it will do 2 things:

  1. Show up in your reports
  2. Be used as behavioral data by our algorithms to calculate recommendations

What situations would warrant this usage? One example is for an email campaign in which your ESP calls Target a bunch of times to generate a batch of personalized emails. You wouldn't want those calls to be recorded as views. Another less realistic example would be if you were using Target calls for the sole purpose of populating your catalog. There are far preferred ways of accomplishing this, e.g. via feeds, or the entity api, but you could imagine why you wouldn't want this catalog-populating activity to be seen by Target as customer activity.

 

Regarding your side note questions: the answer to both of them is yes (but you probably figured this out by now 🙂 

1 reply

cg8Adobe EmployeeAccepted solution
Adobe Employee
February 9, 2023

Hi Nicholas,

 

I know this is 6 months late, but figured I'd answer your questions anyway.

 

detailsOnly is passed in situations where you want to call Target but do not want to record a "view" event. When a view event is recorded, it will do 2 things:

  1. Show up in your reports
  2. Be used as behavioral data by our algorithms to calculate recommendations

What situations would warrant this usage? One example is for an email campaign in which your ESP calls Target a bunch of times to generate a batch of personalized emails. You wouldn't want those calls to be recorded as views. Another less realistic example would be if you were using Target calls for the sole purpose of populating your catalog. There are far preferred ways of accomplishing this, e.g. via feeds, or the entity api, but you could imagine why you wouldn't want this catalog-populating activity to be seen by Target as customer activity.

 

Regarding your side note questions: the answer to both of them is yes (but you probably figured this out by now 🙂 

Level 2
February 9, 2023

Hi @cg8 

I appreciate your very informative reply no matter the date! I'm sure this will also help others in the future that do some searching around this parameter.

Adobe Employee
February 9, 2023

No problem!

 

I forgot to say that the documentation you quoted is a bit misleading in that it sort of implies that those 2 mbox calls are used together, when they should be considered as 2 alternative ways to make the same mbox call, i.e. "do it this way, or that way".