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:
Cons:
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:
Cons:
I will appreaciate your thoughts about it and if you have a better approach it would be nice to know.
Solved! Go to Solution.
Views
Replies
Total Likes
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:
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.
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:
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.
Do you mean having one property for each website? Would you mind clearing that up?
Thanks for your reply!
Views
Replies
Total Likes
Correct, one property for each website.
Views
Replies
Total Likes
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).
Views
Replies
Total Likes
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.
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.
Views
Replies
Total Likes
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?
Views
Replies
Total Likes
Views
Replies
Total Likes
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.
I think we are going to use the third approach that @yuhuisg suggested. Thanks for helping!
Views
Replies
Total Likes
Views
Like
Replies
Views
Likes
Replies