MediaTailor server side tracking

0

I have a question regarding how the tracking events are fired at the server side (start, first quartile, midpoint, third quartile, and ad completion ).

Namely, if i have a preroll with a duration of 10 seconds, i would expect that the midpoint event gets trigger at 5 second mark, and the completed event at 10 second mark. For example : start event is fired at 11:51:40, midpoint event at 11:51:45 and completed event at 11:51:50.

What actually happens is, all tracking events are fired at the pretty much the same time, where the difference between the start and the completed events is maybe a second or two. For example : start event is fired at 11:51:40, midpoint event at 11:51:41 and completed event at 11:51:42.

All of the available events are triggered, with no regards to how many seconds of the ad the user has actually watched. This does not provide correct tracking information.

Am i missing something? Is this how server side tracking is supposed to work? Maybe initial video buffering is triggering all of this events at once?

Any information you can provide is useful. Thanks in advance.

Djole91
asked 3 years ago577 views
5 Answers
0

Hi Djole91, thanks for posting this question!

Client-side reporting allows for very granular reporting as it's the player that responds with what the user has actually watched. If you review the examples at https://docs.aws.amazon.com/mediatailor/latest/ug/ad-reporting-client-side.html you'll note that each beacon event can report against a specific 'startTime' or 'startTimeInSeconds' - so the reporting can be quite detailed.

For Server-side reporting however, the server doesn't have the same granularity and has to make a best judgement based on what segments have been egressed. The reporting accuracy is therefore dependent on the full length of the Ad, as well as the segment length of that Ad, which in this case MediaTailor defaults to 2 seconds. To give you an example:

  • To serve a 10 second Ad where the segment length is also 10 seconds, you would only need to pull one segment for the server to assume that the Ad had been played in its entirety. The server would get all the reporting beacons in one go. Please note this is just an example - MediaTailor doesn't serve Ads with 10s segment lengths using the dynamic transcode profile.
  • To serve a 10 second Ad where the segment length is 2 seconds, the start beacon would be fired with the first segment; the midpoint would be with the third segment, and the complete beacon with the fifth segment. You would see a beacon timestamp with ~2s accuracy.
  • To serve a 30 second Ad where the segment length is 2 seconds, the start beacon would be with the first segment; the midpoint with the 8th segment; and the complete beacon on the 15th segment. You would see a better timestamp representation because the ad content is longer, but still up to 2s accuracy determined by the ad segment length. If the client only egressed segments 1-8 then you would receive the start and midpoint beacon, but not the third quartile or complete beacon.

In summary, dynamic transcode profiles will create 2 second ad segments and therefore the accuracy for server-side beacons will only ever be accurate to 2s. You will see better beacon timestamp accuracy in longer Ad content because it is made up of more segments which can be reported against. If you require more detailed beacon reporting I would consider using client-side reporting.

I hope this answers your question but please let me know if you have any outstanding questions!

AWS
answered 3 years ago
0

Hey bmarshallataws, thank you for a very thorough response. It was very helpful.

I do have one follow-up question.
Since HLS is native on IOS, i cannot control the amount of segments that are going to be buffered. It will do it's own thing.
How would you tackle this specific situation? Are there maybe configuration settings that could be useful?

Djole91
answered 3 years ago
0

Hi Djole91, you're very welcome. That is a great question... this is largely out of our control. Different players will have different logic for how many segments to buffer relative to the play head. DASH has the concept of suggestedPresentationDelay which can influence the presentation delay and how many segments the player will buffer - but this assumes the player in question is designed to look at this value and use it.

In this case server-side reporting reports purely on what the server is doing. If the player downloaded those segments to its buffer, but the user closed the browser before the ad actually played, server-side reporting would still report the Ad as viewed. From the server's perspective the segments have been downloaded and therefore the ad was viewed. For reasons mentioned above, shorter Ads will be more susceptible to this as an entire short Ad could theoretically fit in the player's buffer.

In short, to guarantee accuracy it is best to implement client-side reporting so the client can directly send accurate impression beacons based on how much of the Ad was actually viewed.

AWS
answered 3 years ago
0

Hey bmarshallataws. Thanks for your feedback, it helped me a lot. Take care.

Djole91
answered 3 years ago
0

Glad I could help! You take care too. Best regards.

AWS
answered 3 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions