trackTimedAction reporting logic & behavior questions

tylers52925185

11-09-2018

looking for documentation or other sources to explain some use cases around trackTimedAction(start|update|end).

In particular, looking to understand how it handles non-ideal pairs/sets of timed actions. For example:

  • One 'start' event followed by two consecutive 'end' events - does the report show two completions with separate times to complete for the two end events?
  • Repeated 'start' events before an 'end' event - does the time to complete calculate against the first start event or does it reset every time a 'start' action occurs?
  • 'starts' or 'ends' without any complement - if someone starts but doesn't complete, or gets a completion and somehow skips starting, are those just thrown out?

any insight or advice is appreciated, thanks in advance!

Accepted Solutions (0)

Answers (4)

Answers (4)

tylers52925185

19-09-2018

Not really. These are a separate version of trackAction events, which are different from custom events (in a way). trackTimedActions are very unique in their reporting and behavior, and I'm trying to understand the actual use cases a bit better.

Here's a primer: https://marketing.adobe.com/resources/help/en_US/mobile/ios/timed_actions.html

pabloc82923542

17-09-2018

ok so if i understand the

trackTimedActions

Could potentially be made up of other custom events and all you are doing is putting them together in a fashion as a new custom event.

Did i get that right?

tylers52925185

17-09-2018

Thanks Pablo. This is actually specific to a mobile app implementation that has a feature called trackTimedActions, which have different reporting and behavior from custom events.

pabloc82923542

11-09-2018

Events are instance based. They would be timestamped provided all criteria are met to fire the event.

So if events A -> B -> C are the ideal chronological order then you could segment for that flow or just report instances of each. (FYI the time stamp if trended would only allow an hourly granularity. If seconds are critical then the time of event itself occurring may need to be captured separately as well.

Out of curiosity can you expand on what it is your events are trying to capture? It could be an evar is of use here.