Sent deliveries to different emails (Linked in each campaign) of the same Recipient, without storing it in the schema | Community
Skip to main content
CampaignerForLife
CampaignerForLife
Level 5
July 20, 2023
Solved

Sent deliveries to different emails (Linked in each campaign) of the same Recipient, without storing it in the schema

  • July 20, 2023
  • 5 replies
  • 1372 views

It is necessary to be able to control and modify the contact data for each recipient (email, phone, address, etc.) used in each delivery.

 

In other words, for an email delivery, it should be possible to choose which email address the delivery is sent to for each recipient, without necessarily using the email stored in the recipient schema.

 

For example, a customer creates an account with the email address xxx@gmail.com, and that address is stored in the recipient schema. However, later on, the customer leaves a form on the website with the email address yyy@gmail.com, and additionally signs up for another service with a third address, zzz@gmail.com.

 

Campaign A should be sent to the recipient at the address yyy@gmail.com, and Campaign B to zzz@gmail.com. However, in neither case should these addresses be stored in the data model; they should only be used for those specific campaigns (storing them in the model risks using them in other campaigns).

 

Is it possible to manage this in any way? We have seen that the email used in Target Mapping can be modified, but to do so, it is necessary to select a field that is part of the data model.

 

Thank you in advance!!!

 

@parthasarathy  @_manoj_kumar_ 

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by Craig_Thonis

    Hello,

     

    I believe this can be done, though it depends on whether you want the tracking and logs to roll up into a single recipient profile or separately.

     

    In your use case, if the recipient records should remain separate, the easiest thing would be configuring the subscription or forms to create a recipient record as part of a list. This way the entries are not necessarily a part of the recipient schema and are distinctly separate. At that point, your deliveries simply need to target a specific list.


    If you want the recipient interactions/tracking/preferences from yyy and zzz to be associated with the xxx address then this would require extending the recipient schema and some custom implementation.

    5 replies

    Amine_Abedour
    Community Advisor
    Amine_AbedourCommunity Advisor
    Community Advisor
    July 20, 2023

    Hello @campaignerforlife 

     

    Where do you store  yyy@gmail.com and zzz@gmail.com emails ? 

    What you could do is to store yyy@gmail.com and zzz@gmail.com in other email fields on recipient table (email2 and email3 fields for exemple) and create two new target mapping, one with email2 as email and the second with email3 as email. Then you can use this two target mapping in the deliveries of  your campagin A and campaign B.

    I hope i was clear 🙂 

     

    Br,

    Amine

     

     

    Amine ABEDOUR
    Amine_Abedour
    Community Advisor
    Amine_AbedourCommunity Advisor
    Community Advisor
    July 20, 2023

    Hello @campaignerforlife 

     

    What you can do is store the yyy and zzz emails on dedicated fields on recipient table (let say  email2 and email3 fields).

    Then create two new target mapping where you specifie email2 as the email for the first one and email3 as the email for the second one. Then you can use this new taget mapping in the deliveries in you campaign A and cmapaign B respectively.

     

    hope i was clear 😊 

     

    Br,

    Amine

    Amine ABEDOUR
      Craig_Thonis
      Adobe Employee
      Craig_ThonisAdobe EmployeeAccepted solution
      Adobe Employee
      July 20, 2023

      Hello,

       

      I believe this can be done, though it depends on whether you want the tracking and logs to roll up into a single recipient profile or separately.

       

      In your use case, if the recipient records should remain separate, the easiest thing would be configuring the subscription or forms to create a recipient record as part of a list. This way the entries are not necessarily a part of the recipient schema and are distinctly separate. At that point, your deliveries simply need to target a specific list.


      If you want the recipient interactions/tracking/preferences from yyy and zzz to be associated with the xxx address then this would require extending the recipient schema and some custom implementation.

        DavidKangni
        Community Advisor
        DavidKangniCommunity Advisor
        Community Advisor
        July 20, 2023

        @campaignerforlife 

        You will still need to create a target mapping as below. In my use case it was loyalty account for a brand with multi business unit and customer can provide different emails for each BU. I used an enrichment to add the needed email and name the alias as @email

         

        Thanks,

        David

         

        David Kangni
          LakshmiPravallika
          Community Advisor
          LakshmiPravallikaCommunity Advisor
          Community Advisor
          July 24, 2023

          Hi @campaignerforlife ,

           

          Yes it is necessary for that email field captured from the form to be present in the Schema as it should be targeted to send the Campaigns.

           

          However, you can restrict those fields (Both the email Addresses which you will store in a Schema) access to specific Operators/Operator Groups so that you can have Access Management for those Data.

           

          In your Use case, you have to create 2 different Target Mappings to target these 2 Email Address Fields (1 for each) and use them in your Delivery activity :

           

           

          You can even restrict the Delivery/Tracking/Exclusion logs getting generated based on  the Operator level for the Schema having the Email Fields.

           

          Regards,

          Pravallika.

           

           

            Terms & ConditionsAccessibility statement

            Loading footer...