What is preferrable: Client-side or Server-side implementation

[jp_behrens]

Hello,

I'm not a developer myself so I'm not intimate to server vs. client side implications, but I am in charge of designing technical specs for our implementation. I recently found this article from a previous discussion posted on the board: https://marketing.adobe.com/developer/documentation/data-insertion/c-limitations  I have a couple of questions after reading this:

1. This first is a question one of my tech leads always asks me, is it preferable to implement server-side or client-side? what is the best practice? I'm seeing that our developers opt to implement server-side when possible, but it seems like that comes with a high degree of difficulty given the back and forth we always go into when implementing.
2. We don't use a tag managment system yet but are thinking about implementing DTM. Does sever vs client side implementation affect in any way how to implement DTM? Again, what is the preferred way to do it?

Thanks!

[brandonb4574468 · Accepted solution]

1. Client-side implementation is standard and allow for enhanced out-of-box functionality (e.g., data on browsers/user agents, operating systems, screen resolutions, device types). In theory, it's possible to replicate this functionality in a server-side implementation, but at that point you're recreating the wheel and might as well build your own analytics solution.

2. DTM is, at heart, a way to inject JavaScript into a page without having to jump through any development hoops in pushing actual page code changes. If you're going with a server-side implementation, I can't think of any use for DTM (as the JavaScript would be injected into the client-side application).

A typical DTM implementation, to my knowledge, would be:

1. Your site exists as a collection of pages that inherit from a base template.
2. Create a staging report suite in Adobe Analytics.
3. Add DTM bootstrap code to your site's base template in staging and production environments (DTM gives you 2 different URLs -- one for your staging library, one for your production library).
   • (If you're not using a base template, you'll need to add the DTM bootstrap code to every page individually.)
4. Use your DTM staging library to build rules; test these rules in your site's staging environment; data is collected in your staging report suite.
5. When ready...
   • create a new production report suite based on your staging report suite (copies settings, not data)
   • add this production report suite to your DTM setup
   • add production DTM library URL to your production site template (or each page, individually)
   • publish your DTM rules -- this will push them into your production DTM library, so they'll fire on your production site, and data will be collected in your production report suite

[jp_behrens]

What about implementing variables that you know will always have a specific value on a page, like for example the pageName variable, would that make sense to implement server-side? If so, would it still be preferrable to implement client-side? 

[brandonb4574468]

With respect to the Adobe Analytics implementation, it's client-side.

From my last post -- in point 3, in addition to adding the DTM bootstrap code you would add a small <script> section to set any variables that were effectively generated server side.

So, for your home page, your page would have your back-end system generate the typical HTML, and then just add, for example:

<script> dataLayer = {};  // an empty object to store variables from server-side logic dataLayer.pageName = "pageName/to/populate/Adobe/Analytics"; dataLayer.channel = "channel_for_Adobe_Analytics"; dataLayer.prop1 = "prop1_value_for_Adobe_Analytics"; </script>

You have several options for mining this data in DTM; the most straight-forward way would be to use a "Data Element" to look for the applicable JavaScript variables and send those over to your Adobe Analytics implementation.

So, your server-side process writes variables into the page code that are then read by Adobe Analytics on the client-side.

This pattern (creating a data layer, regardless of whether you actually name it "dataLayer" like my example) is quite common for larger websites where server-side knowledge needs to be transferred to client-side applications but not actually written to the screen.