1

In the Marketing Cloud portal there is only one paragraph of text about Attribute groups. I have the model described in the picture. enter image description here

I have created a population for Account.

I have defined the following two attribute groups for this model.

Here they are:

Account_Order: In which (1) from the population Account.Id has a one-to-many relationship with Order.AccountId and (2) Order.ProductId has a many-to-one relationship with Product.Id.

Account_Interest: In which (1) from the population Account.Id has a one-to-many relationship with Account_Interest.AccountId and (2) Account_Interest.InterestId has a many-to-one relationship with Interest.Id.

Do I have the whole picture wrong?

2

You seem to have the picture correct. Whether these are two attribute groups or one doesn't matter too much. Attribute groups are really only to logically group Data Extensions into topics. Having many can actually get in the way, but your suggestion looks good. One consideration would be whether you use Account as your population. They've replaced the old "Root" data extensions with this "Population" concept and it does impose some limitations on you going forward. Principal issue I see is that once Account is a Population, the only way you can relate Data Extensions to it is through the ContactKey/AccountID. So, taking your example there, you'd not be able to add a reference table for "Streams" because you can't join from the Population to the new Streams reference table as the Streams table does not contain the AccountID. I'm tending at the moment to either import all my accounts into All Subscribers (which is also a population) or create a separate useless table that just contains the AccountID and the EmailAddress to keep Contact Builder happy and add my Account table into an attribute group like any other table. That way I maintain the flexibility to add further tables that don't necessarily join to Account through AccountID. Just a consideration.

  • Thanks for the comment. To cut a long story short, there will not be any Steam table, so no worries about that for now. But regarding your advice on starting with the ContactKey/AccountID connection, I don't know why I cannot get this to work. Because once I try to create a new relationship, my Account data extension is absent from the list on the right while other data extensions are there. Is it because I defined Account as a population? – Disasterkid May 19 '17 at 7:04
  • 1
    Yes. That's exactly what I was alluding to. You basically use up your chance on using Account for anything else. The only way you can join to it once it's a population is through the ContactKey (AccountID). – Macca May 19 '17 at 7:23
  • Sorry, a bit confused. The only way is through connecting Customer Data's ContactKey to Account population's AccountID? This does not look possible on my canvas at least. – Disasterkid May 19 '17 at 7:30
  • 1
    If you've added the Account table as a Population, you can no longer use it for relationships in Attribute Groups directly. The Account.ID is linked to ContactKey as part of the set up of the Population. From here on in, the only way you can join any table in the Attribute Groups back to the Account table is by relating them to the Contact.ContactKey (which is the same as your Account.ID). – Macca May 19 '17 at 7:50
  • 1
    Yeah. It sounds like you're on the right path with your configuration. If relating back to account in any other way isn't an issue, I don't see anything wrong with what you're doing at all. – Macca May 19 '17 at 8:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.