Avoiding "Dropouts" (or: how to signal Deal changes)

Adding a new Offering

Assume this scenario:

A label has communicated to a DSP that a Release can be made available to consumers in a specific territory as a download from, say 1^st May. Today is the 15^th May and the DSP has made the Release available as instructed.

Let's further assume that the label wants to make the Release also available, in the same territory, as a stream from 1st June onwards. The download deal is unaffected from this new offering. To avoid that the download offering disappears, the following deals should be communicated on 15^th May:

• Deal 1: Download from 1^st May^(*)

• Deal 2: Stream from 1^st June

The reason for the DSP's behaviour is that a NewReleaseMessage always communicates a "statement of truth". It thus provides the complete picture of what Deals are available for a specific Release.

Changing an existing Offering

Assume this scenario:

A label has communicated to a DSP that a Release can be made available to consumers in a specific territory as a download from, say 1^st May for £5. Today is the 15^th May and the DSP has made the Release available as instructed.

Let's further assume that the label wants to reduce the price, in the same territory,  from 1st July onwards to £4.  To avoid that the download offering disappears, the following deals should be communicated on 15^th May:

• Deal 1: Download from 1^st May for £5

• Deal 2: Download from 1^st July for £4
  

(*) – While it is recommended that the label uses the same start date as in the original deal – here: 1^st May – it is also permissible that the label uses the date on which the update message is sent. It is cruciual, however, that the start date for Deal 1 is not in the future.