Responsys - Populate Customer_Id_ in the Ced for Program and Holdout group

Luca Trevisani
Luca Trevisani Posts: 12 Green Ribbon
edited Jul 6, 2021 4:33PM in Dream It


now the column Customer_id in the CED for Program and Holdout groups is blank. As for all the CED files as SENT, CLICK, OPEN, etc, it would be very useful to have that field populated with the Customer_id of the users.


4 votes

Under Oracle Review · Last Updated

The idea is under consideration by Oracle


  • Sachin Jain-Oracle
    Sachin Jain-Oracle Mr Posts: 164 Employee

    HI Luca,

    Thank you for submitting your idea. We are very interested in your thoughts on any features you want to see in our product. The product team has considered the request to support the Holdout Groups CED. Please keep an eye on our Responsys Release Center for updates on when this might be available: https://community.oracle.com/topliners/discussion/4477587/oracle-responsys-release-center. Whereas, team have decided not to move forward with the Program CED output idea submission at this point in time.

    Again, we thank you for your time and welcome any suggestions.

    Thank you

    Sachin Jain

    CX Community Manager

    Stay Safe | Stay Healthy

    Thanks, and Best Regards

    Sachin Jain | CX Community Manager

  • I believe there is a workaround for this.

    With the workaround described below, Program can populate the CUSTOMER_ID_ field as an entry tracking variable (ETV). When Program writes out the event to the event table, it will pass both the RIID_ and the CUSTOMER_ID. This in turn gets the CUSTOMER_ID into the Holdout CED file.

    There are two variants for this setup, depending on the starting events used in the program.

    SQL View as the starting event, then you can set GetData to match on the Entry Tracking Variable value and it should work

    Scheduled Filter as the starting event, you need to set the GetData match value to -optional-


    To bring the CUSTOMER_ID into the program:

    • Create a SQL view on the profile list that gets the CUSTOMER_ID. We recommend storing the SQL view in a central folder of SQL queries for the account.
      • Example: When selecting RIID_ and CUSTOMER_ID_ from the profile list specified when you create the SQL view, your SQL statement should look like the following. It extracts the CUSTOMER_ID_ value as a column name matching the entry tracking variable CUSTOMER_ID. $A$ is the table alias.

               select RIID_, CUSTOMER_ID_ as CUSTOMER_ID from $A$;

    • In your program orchestration, create an entry tracking variable (CUSTOMER_ID) of type Text.


    • Add the Get-Data stage (using SQL view you created in step 1) after the Allocation switch and before the Holdout group stage in the program, as follows.


  • Luca Trevisani
    Luca Trevisani Posts: 12 Green Ribbon

    Hi Jennifer,

    yes, but as you said this solution is workaround. Using the workaround I see two main risks:

    1 - Using an sql view in the program could slow down the entire process

    2- The client must use the sql view and the entry tracking variables even if not they are not needed for the use case

    Do you agree with me?