Compliance Testing
MassiveMusic has rights holder reporting obligations, each individual service will have bespoke reporting requirements. Due to this, it is crucial that we have correct log data from which we can generate the required reports.
The logging API allows you to report playback activity back to MassiveMusic, for the purposes of licensor royalty and usage reporting. There are 4 different API endpoints, these are: subscription stream, catalogue stream, download sales and preview clips.
The processes outlined below allows MassiveMusic to ensure the data is accurate from the source where the data is logged.
Process:
Step 1: Testing instructions and a Development API key(s) will be sent to you so that you can begin Compliance Testing.
Step 2: You test according to whatever service type you fall under (i.e. download, subscription streaming, catalogue streaming or preview clips).
Step 3: Once you have completed testing, you would email the Client Success team via MassiveMusic's support email address [email protected]. and attach a CSV file of the data you have logged during the test period.
Step 4: MassiveMusic reviews the assets you sent and if everything is there then we pass this over to our Reporting Team.
Step 5: MassiveMusic’s Reporting Team then reviews the logs. This process takes up to 5 working days and we will let you know once complete. Once this process is complete, we will send you an Excel file with your logs and ours so you can see the direct comparison. If there are any non-compliant areas this will be flagged to you so you can correct.
Step 6: Once you have put a fix in place for these areas, you would then send over the new logs (steps 4 & 5 will be repeated until the data pulls through correctly).
Step 7: The compliance process is complete. MassiveMusic will then send you your live keys and you can launch. The Development API key(s) will still be open so, feel free to use this to do any testing you may need post compliance approval.
Select a service type from below to see more details on how testing should be conducted:
Before you get started
- Please ensure you conduct the tests on the Development API key(s).
- Please note down the time and date (UTC) that you begin the test usage activity, and the same for when you cease the test usage activity.
- Once your logging activity has been approved, we highly advise and recommend retaining a backup of all your logs on a monthly basis.
- During the testing window you must only log compliance data and should not log any other development activity to MassiveMusic’s platform during the testing window.
- Either need to create a test compliance key or put in place a 24 hour blockage for Developers when testing, this information will be used to reconcile the data you have logged via the logging endpoints.
Testing Instructions
-
Set-up 10 test users via user/create on your test Development API key(s), Mobile and Web (if applicable). Authorize the users for streaming via user/unlimitedStreaming.
-
Over a 24 hour period conduct streaming for all 10 test users via stream/subscription. For each test user there should be around 10-50 streams.
-
Log the streams via user/subscription/log .
- Use a variety of different label content.
- Ensure you note down the date and times that you start and end the testing.
-
For the same data that you logged on user/subscription/log please also provide to us the exact same data in a CSV file to the Client Success team via MassiveMusic's support email address [email protected], and similarly, please also provide us with the data you logged on user/unlimitedStreaming in a separate CSV file. The headers we require in the CSV are listed below.
MassiveMusic manages the rest. We compare the data from our log tables to the 2 CSV files you have provided, looking for a 100% match. When this is achieved we will be able to build and begin validating reports with the rights holders.
Reporting Template
The CSV file of logs that you send to MassiveMusic must contain the following headers and data:
Stream Log Template:
Header | Required / Optional | Description |
|---|---|---|
userId | Required | The unique identifier of the user. |
country | Required | ISO 2-character code of the country the end user resides in. |
trackId | Required | The MassiveMusic ID of the track that was streamed. |
releaseId | Required | The MassiveMusic release ID of the release that was delivered to the user. If a track was delivered this needs to correctly identify the release that the track appears on. |
formatId | Required | The MassiveMusic ID of the format streamed. |
userAgent | Required | Details of the device model and application version used to play the track. Values over 256 characters will be truncated. |
dateTimePlayed | Required | The date and time when the track was played. Should be in the ISO 8601 format. |
totalTimePlayed | Required | The total time the track was streamed in seconds (or 0 if it was only pre-fetched and never played). |
playMode | Required | Either “online”, “offline”, or “online-cached”. Indicates if the play was with an active or inactive network connection and if the network connection was active, whether or not it was read from the device cache. |
User Log Template:
| Header | Required / Optional | Description |
|---|---|---|
| userId | Required | The unique identifier of the user. |
| planCode | Required | Please contact your Client Success Manager for more detail on how to supply the correct planCode. |
| status | Required | The status of the subscription must be set as active. |
| currency | Required | ISO 4217 currency code, identifying the currency in which the end user has paid. |
| recurringFee | Required | The amount in cents charged to the subscriber for the current subscription. If a voucher has been used then recurringFee should be 0. |
| postcode | Optional | The postcode of the subscriber if applicable. |
| country | Required | ISO 2-character country code where the subscriber is located. |
| activatedAt | Required | ISO 8601 UTC date-time format. The date and time when the user first activated any type of subscription. ActivatedAt must be now or earlier. |
| currentPeriodStartDate | Required | ISO 8601 UTC date-time format. The date and time when the current subscription started.CurrentPeriodStartDate must be no more than 1 day from now, and the same as or later than activatedAt. |
| trialEndsAt | Optional | ISO 8601 UTC date-time format. This is the date and time of when a trial period ends. If you are using a trail plan code, then this value must be populated. Otherwise this parameter must not be supplied. Please contact your Client Success Manager for more detail on how to supply the correct planCode. TrialEndsAt must be later than currentPeriodStartDate and no more than 100 days from currentPeriodStartDate. |
| expiryDate | Required | ISO 8601 UTC date-time format. The date and time when the subscription is due to expire. ExpiryDate must be no more than 1 month from currentPeriodStartDate. If the subscription was a trial, expiryDate must also be the same as or later than trialEndsAt. In the exceptional case that trialEndsAt is more than 1 month from currentPeriodStartDate, expiryDate must be equal to trialEndsAt. |
Before you get started
- Please ensure you conduct the tests on the Development API key(s).
- Please note down the time and date (UTC) that you begin the test usage activity, and the same for when you cease the test usage activity.
- Once your logging activity has been approved, we highly advise and recommend retaining a backup of all your logs on a monthly basis.
- During the testing window you can only log compliance information.
- Either need to create a test compliance key or put in place a 24 hour blockage for Developers when testing, this information will be used to reconcile the data you have logged via the logging endpoints.
Testing Instructions
-
If you set-up external users for your service on our system, set-up 10 test users via user/create on your test Development API key(s), Mobile and Web (if applicable). (Note, if you don’t set-up users on our system you must still provide a User ID value in the stream logs, as we need to identify each user’s activity for compliance and reporting purposes.
-
Over a 24 hour period conduct streaming for all 10 test users via conduct streaming via stream/catalogue. For each test user there should be around 10-50.
-
Log the streams via catalogue/log .
- Use a variety of different label content.
- Ensure you note down the date and times that you start and end the testing.
- Ensure you apply a User ID value for each user, whether created on our system or not, and include that User ID value in the stream log.
-
For the same data that you logged on catalogue/log please also provide to us the exact same data in a CSV file to the Client Success team via MassiveMusic's support email address [email protected]. The headers we require in the CSV are listed below.
MassiveMusic manages the rest. We compare the data from our log tables to the 2 CSV files you have provided, looking for a 100% match. When this is achieved we will be able to build and begin validating reports with the rights holders.
Reporting Template
The CSV file of logs that you send to MassiveMusic must contain the following headers and data:
| Header | Required / Optional | Description |
|---|---|---|
| userId | Required | The unique identifier of the user. |
| country | Required | ISO 2-character code of the country the end user resides in. |
| trackId | Required | The MassiveMusic ID of the track that was streamed. |
| releaseId | Required | The MassiveMusic ID of the release that was streamed. |
| formatId | Required | The MassiveMusic ID of the format streamed. |
| dateTimePlayed | Required | The date and time when the track was played. Should be in the ISO 8601 format. |
| totalTimePlayed | Required | The total time the track was streamed in seconds (or 0 if it was only pre-fetched and never played). |
| endReason | Required | The reason the track play was stopped. This is one of three values "naturalEnd", "userSkipped" or "other." "naturalEnd" would be used to indicate when a track has finished playing in its entirety. "userSkipped" would be used to indicate that a user has chosen to skip the currently playing track. "other" is used when the reason the track has been stopped doesn't fit into the previous categories, for example when a user changes radio station. |
| userAgent | Required | Details of the device model and application version used to play the track. Values over 256 characters will be truncated. |
Before you get started
- Please ensure you conduct the tests on the Development API key(s).
- Please note down the time and date (UTC) that you begin the test usage activity, and the same for when you cease the test usage activity.
- Once your logging activity has been approved, we highly advise and recommend retaining a backup of all your logs on a monthly basis.
- During the testing window you can only log compliance information.
- Either need to create a test compliance key or put in place a 24 hour blockage for Developers when testing, this information will be used to reconcile the data you have logged via the logging endpoints.
Testing Instructions
-
Set up 10 test users via user/create on your test Development API key(s), Mobile and Web (if applicable).
-
Over a 24 hour period conduct downloading for all 10 test users via user/deliveritem. For each test user there should be around 10-50 streams.
- Use a variety of different label content.
- Ensure you note down the date and times that you start and end the testing..
-
For the same transactions that you logged on user/deliveritemplease also provide to us the exact same data in a CSV file to the Client Success team via MassiveMusic's support email address [email protected].The headers we require in the CSV are listed below.
MassiveMusic manages the rest. We compare the data from our log tables to the 2 CSV files you have provided, looking for a 100% match. When this is achieved we will be able to build and begin validating reports with the rights holders.
Reporting Template
The CSV file of logs that you send to MassiveMusic must contain the following headers and data:
| Header | Required / Optional | Description |
|---|---|---|
| userId | Required | The unique identifier of the user. |
| transactionId | Required | The transaction ID you provided for the initial transaction when calling the ~user/deliveritem endpoint. |
| purchaseId | Required | The MassiveMusic purchase ID returned in the response from your call to the ~user/deliveritem endpoint. |
| purchaseStatus | Required | Identifying whether the data in this row relates to a Purchase or Refund. |
| purchaseDateTime | Required | The date and time (in UTC) of the purchase in ISO 8601 UTC date-time format. |
| refundDateTime | Optional | If the Purchase Status identifies a refund then you must provide the refund date and time in ISO 8601 UTC date-time format. |
| country | Required | ISO 2-character code of the country the end user resides in. |
| currency | Required | ISO 4217 currency code, identifying the currency in which the end user has paid. |
| rrp | Required | The MassiveMusic RRP of the release or track from the purchase. |
| purchasePrice | Optional | If you are charging your users different prices than the MassiveMusic RRP please include the Purchase Price. This should include fractional units in decimal form where relevant for the currency in question, eg. "7.99", "1.00". The price must not be negative, must not be more than 2 decimal places and must not include any commas (","). |
| artistId | Required | The unique MassiveMusic identifier of the artist. |
| releaseId | Required | The MassiveMusic release ID of the release that was delivered to the user. If a track was delivered this needs to correctly identify the release that the track appears on. |
| trackId | Optional | If supplied, this specifies that only the track was delivered. The MassiveMusic track ID of the track that was delivered to the user. |
| artistName | Required | The artist name of the release or track which was purchased. |
| productName | Required | The title of the release or track which was purchased. |
| licensorName | Required | The name of the licensor the product is distributed by. |
Before you get started
- Please ensure you conduct the tests on the Development API key(s).
- Please note down the time and date (UTC) that you begin the test usage activity, and the same for when you cease the test usage activity.
- Once your logging activity has been approved, we highly advise and recommend retaining a backup of all your logs on a monthly basis.
- During the testing window you can only log compliance information.
- Either need to create a test compliance key or put in place a 24 hour blockage for Developers when testing, this information will be used to reconcile the data you have logged via the logging endpoints.
Instructions
-
Set up 10 test users via user/create on your test Development API key(s), Mobile and Web (if applicable).
-
Over a 24 hour period conduct conduct a few plays each day on preview.7digital.com/clip using the 10 test users, For each test user there should be around 10-50 streams.
- Use a variety of different label content.
- Ensure you note down the date and times that you begin the testing and end the testing.
-
For the same plays that you logged on preview/log please also provide to us the exact same data in a CSV file to the Client Success team via MassiveMusic's support email address [email protected]. The reporting template is outlined below.
MassiveMusic manages the rest. We compare the data from our log tables to the 2 CSV files you have provided, looking for a 100% match. When this is achieved we will be able to build and begin validating reports with the rights holders.
Reporting Template
The CSV file of logs that you send to MassiveMusic must contain the following headers and data:
| Header | Required / Optional | Description |
|---|---|---|
| country | Required | ISO 2-character country code where the subscriber is located. |
| trackId | Required | If supplied, this specifies that only the track was delivered. The MassiveMusic track ID of the track that was delivered to the user. |
| dateTimePlayed | Required | The date and time when the track was played. Should be in the ISO 8601 format. |
| totalTimePlayed | Required | The total time the track was streamed in seconds (or 0 if it was only pre-fetched and never played). |
| userId | Required | The unique identifier of the user. |
| playMode | Required | Either “online”, “offline”, or “online-cached”. Indicates if the play was with an active or inactive network connection and if the network connection was active, whether or not it was read from the device cache. |
Updated 5 months ago