Skip to main content

Data Submission to CDC

Introduction​

From the initial overview of webforms ORCA - Data - Web Forms and then the consideration of the required form schemas and resulting submitted data payloads ORCA - Web Forms - Form Definition Schemas - 01. Newsletter Sign-up, we come to the topic of exporting the submitted data to CDC … as needed.

CDC is a downstream system from the perspective of webforms, and hence we consider

CDC is a downstream system

Streamline the process​

In order to streamline the processes involved, it makes sense to consider the requirements of CDC when implementing the solution.

  • The initial form rendering and user entry is determined by the form definition schemas.

    • CDC has a standard payload model
    • the required attributes from the model should be supplied
    • specifically the values expected should be defined by CDC

  • The data submission should be in accordance with the CDC payload model

    • the customer profile is a major component of the data submission, and hence the data model of the data submission from the form, and the data model of CDC should align as far as possible
    • there may be other elements in the data submission outside of the attributes CDC expects, so their correct handling needs to be agreed e.g. binary files, lengthy survey feedbacks

  • Data validation, implemented by the form solution, should match the expectations of CDC

    • e.g. a dateOfBirth in “YYYY-MM-yy” datetime format should be given rather than “age” as an integer
    • as well as basic security and content checks to ensure the submission is safe and using the correct format

  • Data Transformation

    • Where possible the same model (e.g. key:value) pairs should be used.

    • The ideal is 100% alignment between the data submission payload model, and the CDC model to eliminate any data transformation activity even if only mapping from one key to another without changing the value.

CDC Basics​

It is SAP Customer Data Cloud - https://help.sap.com/docs/SAP_CUSTOMER_DATA_CLOUD

In Essity, CDC is best understood by visiting https://scadev.atlassian.net/wiki/spaces/ECP/overview?homepageId=4005396928

Submission to CDC​

Submission to CDC needs to consider

CDC Payload​

The CDC payload is currently defined at https://scadev.atlassian.net/wiki/spaces/ECP/pages/4657741825/Baseline+Payload

which is characterised by

  • api data
  • payload metadata
  • numerous personal profile key:value attributes
  • an array of Q&A pairs
  • an array of preferences
  • an array of subscriptions

Most of the entities in the payload are straightforward key:value pairs - these can be readily adopted in any form definition schema.

Q&A pairs​

The Q&A pairs are structured as e.g.

Q&A pairs
    "questions": {
        "Q000001": {
            "questionDescription": "Which gender are you shopping for?",
            "answers": [
                "A000503"
            ],
            "answersDescription": [
                "MaleăîșțâĂÎȘȚÂ,ăîîșțâ,!@#$@#$%^"
            ]
        },
        "Q000002": {
            "questionDescription": "How tired do you feel?",
            "answers": [
                "A000003"
            ],
            "answersDescription": [
                "Mildly Tired"
            ]
        },
        "Q000003": {
            "questionDescription": "Which age range are you looking to buy for?",
            "answers": [
                "A000030"
            ],
            "answersDescription": [
                "18-29"
            ]
        },    
    }

Each question has a unique ID, together with attributes which describe the question and the answer given.

  • the “questionDescription” - the text of the question asked.
  • the “answers“ - Id of the chosen answer(s)
  • the “answersDescription“ - the text of the chosen answer

Question and Answer IDs are specific to the localized version of the values. Separately, within the CDC space, there is a reference to the master (English) ID.

So preparation of the specific form definition needs to consider using existing Q&A pairs. If those pairs are not suitable, it is recommended to generate new ones within CDC which can be used on current and future forms. This approach may seem slightly cumbersome, but allows the reuse of existing Q&A pairs across multiple forms.

Continuing our example of using JSON Schema to define the model

An array of form question and answer pairs - https://digitalmarketing.schemas.essity.com/form-questions-and-answers.schema.json
{
  "$schema":"https://json-schema.org/draft/2020-12/schema",
  "$id":"https://digitalmarketing.schemas.essity.com/form-questions-and-answers.schema.json",
  "description":"An array of form question and answer pairs",
  "type":"object",
  "required":["questions"],
  "properties":{
    "questions":{
      "description":"User's confirmation of being over 18 years of age",
      "$ref":"https://digitalmarketing.schemas.essity.com/form-question-and-answers.schema.json"
    }
  }
}
A question and answers pair - https://digitalmarketing.schemas.essity.com/form-question-and-answers.schema.json
{
  "$schema":"https://json-schema.org/draft/2020-12/schema",
  "$id":"https://digitalmarketing.schemas.essity.com/form-question-and-answers.schema.json",
  "description":"A question and answer pair",
  "type":"object",
  "required":["questionId","answers"],
  "properties":{
    "question":{
      "questionId":{
        "type":"string"
      },
      "answers":{
        "type":"array",
        "items":{
          "$ref":"https://digitalmarketing.schemas.essity.com/form-answer.schema.json"
        }
      },
    }
  }
}
Form answer object - https://digitalmarketing.schemas.essity.com/form-answer.schema.json
{
  "$schema":"https://json-schema.org/draft/2020-12/schema",
  "$id":"https://digitalmarketing.schemas.essity.com/form-answer.schema.json",
  "description":"Form answer object",
  "type":"object",
  "required":["answers"],
  "properties":{
    "answer":{
      "answers":{
        "type":"string"
      },
      "answersDescription":{
        "type":"string"
      }
    }
  }
}

Preferences​

This is an array of items which capture relevant agreements to preferences.

A simple example would be

"preferences": {
    "terms.TENA_FR.isConsentGranted": true,
    "privacy.TENA_FR.isConsentGranted": true
}

These preferences are identified with a key formed as a concatenation of “preference_type.Brand_CC.isConsentGranted”.

In terms of schema

Form preferences array - https://digitalmarketing.schemas.essity.com/form-preferences.schema.json
{
  "$schema":"https://json-schema.org/draft/2020-12/schema",
  "$id":"https://digitalmarketing.schemas.essity.com/form-preferences.schema.json",
  "description":"Form preferences array",
  "type":"object",
  "required":["preferenceName","preferenceValue"],
  "properties":{
    "preferences":{
      "type":"object"
    }
  }
}

Each preference is expressed as a key:value object, and with so many permutations, it is not feasible to explicitly define each key, in the schema.

Subscriptions​

This is an array of items which capture relevant agreements to subscriptions e.g.

"subscriptions": {
    "newsletter.TENA_FR.email.isSubscribed": false
}

These subscriptions are identified with a key formed as a concatenation of “subscription_type.Brand_CC.channel.isSubscribed”.

In terms of schema

Form subscriptions array - https://digitalmarketing.schemas.essity.com/form-preferences.schema.json
{
  "$schema":"https://json-schema.org/draft/2020-12/schema",
  "$id":"https://digitalmarketing.schemas.essity.com/form-subscriptions.schema.json",
  "description":"Form subscriptions array",
  "type":"object",
  "properties":{
    "subscriptions ":{
      "type":"object"
    }
  }
}

Each subscription is expressed as a key:value object, and with so many permutations, it is not feasible to explicitly define each key, in the schema.