Best practices using one property for many different websites in Adobe Launch

[ArlemGabriel]

Hi everyone and thanks in advance for your help!

Right now I have one property with several rules (Page Load, Click Action, etc) and different websites are using the same property for tagging implementation. Since I'm Junior developer and pretty new to analytics world I was wondering which could be the best approach to keep rules consistent and also maintainable over time. I came up with two approaches but I'm not sure if it is the best way to achieve it:

First Approach: Have one single rule that is going to be share with all the websites. For instance: Having only one page loaded event which will contain global variables and customized variables for each portal.

Pros:

• There is going to be only one place in which I would have all the evars needed, in case of remove, update or add a new one there is going to be only one place to do it

Cons:

• It could be a mess in terms of having a lot of evars from many different portals because I will not be able to know which eVars are from one site and another. Everything will be mixed.
• That rule will contains actions that aren't going to be used for all the websites. For instance: Use set variables of AA Product Builder (some websites may not have products only single page loaded events)

Second Approach: Have one global rule with all global variables and customized rules for every different website. For instance: Having one global page loaded event which is going to have all the global variables that are going to be the default for every site and then create a Customized Page Loaded for every single site which will contains only the evars customized for that specific site.

Pros:

• I will be able to differenciate which eVars are from every site since there is going to be a customized rule per site.
• Every single rule will contains only the requirements for that specific website. For instance: Use set variables of AA Product Builder (only the websites that have products will have the set variables action of this extension)

Cons:

• There is going to be different places with the evars that means that in case of remove, update or add a new one there is going to be more places to do it.

I will appreaciate your thoughts about it and if you have a better approach it would be nice to know.

[yuhuisg · Accepted solution]

Would you be willing to consider a Third Approach?

I'm kind of in a the same situation as you, where the client has only one global report suite, but has many different properties. So I proposed going with this approach, so:

• Every property must set the same global eVars, events, etc.
• Each property can set its own eVars, events, etc.
• All properties' Adobe Analytics send data to that one report suite.

We went with this setup because each property was different in nature, e.g. one was informational, another was transactional, another was for lead generation, etc. Having a single property turned out to be too messy in terms of management, and also made it difficult to name the rules and data elements properly. (Yes, naming stuff turned out to be a huge factor too!)

If you go with this approach, then you can keep the data layer in the websites, but change the <script> snippet to the appropriate one for its Launch property.

One con is that if there are new global eVars/events/etc, then you need to change-and-publish all of the properties too.

[ArlemGabriel]

Do you mean having one property for each website? Would you mind clearing that up?

Thanks for your reply!

[yuhuisg]

Correct, one property for each website.

[ArlemGabriel]

We thought about using that approach but actually we decided to have only one property for all the websites. The reason was the one that you mentioned at the end (if we want to create, update or remove one evar/event/etc then we have to go through each property to do that change). 

[yuhuisg]

Personally, I'd lean towards the First Approach: my experience has been that even with global eVars/events, sometimes there are nuances even with how the data elements that populate the eVars/events are set between websites. So with that additional complication, I think it makes the Second Approach even less manageable.

On the other hand, if there are a lot of websites (e.g. >10) that you need to manage, then the Second Approach makes more sense, but you'd need some creativity to ensure your data elements are set properly if, again, there are differences in how they are set in each website.

[ArlemGabriel]

Thanks for your help @yuhuisg. We'll try the third approach that you shared! I think it's the better one since we also found that if our analytics team grow we are going to have a lot of issues publishing the libraries because if we have all the websites in the same prop then all of the developers must work in the same prop even if they are working in different websites features and since we can only have one library in stage that would be a disaster in terms of time and communication.

[rudraWiley]

Hey,

Considering we have 2 different property for 2 different website domains but sending data to same report suite.  what will happen to ECID (marketing cloud id)? with different property, would they be different or same?

@Jacob-DDdev @yuhuisg @ArlemGabriel 

[yuhuisg]

Duplicate question: https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-questions/transfer-ecid-from-one-pr...

[Jacob-DDdev]

Hi @ArlemGabriel , I second @yuhuisg 's suggest of approach 1, but I don't fully understand the issue of setting evars that aren't used for other sites since Launch will not include evars in the beacon if they have not been set.

The only issue with that approach would be if they are set, but don't map correctly to different report suites.If you are mapping to different report suites with different evar/prop definitions, you may find it much easier to set up Launch to send consistent context data for every site, and then, when configuring your report suites, you can map context data into the appropriate evar/prop.

[ArlemGabriel]

I think we are going to use the third approach that @yuhuisg suggested. Thanks for helping!