Adobe Analytics: How to write Technical Specifications

The creation or design of ‘Technical Specifications’ is an essential task of an architect. If you are an Architect, you should have come across the range of Technical Specifications based on the Business Requirements / you should at least have an idea of it.

‘Technical Specifications‘ is the document to bridge functional and technical platforms i.e. Business and Development Teams. It translates the Business Requirement into comprehensible language for any developer who can understand the technical jargons. Effective creation and maintenance of Technical Specifications is critical and without the same, errors can occur during implementation and updates.

Said that, how do you design an optimal Technical Specifications for Adobe Analytics? I know  there are professionals who can do this with ease, but from my knowledge, below is how I used to build Technical Specifications. I can guarantee that if you can cover the below points for your technical specifications, you can protrude the minimal expectation on creating Technical Specifications for Adobe Analytics.

Note: Do not misinterpret Technical Specifications with Solution Design Reference(SDR). Solution Design Reference(SDR) is a high level documentation which hold Goals, KBR, KRAs, KPIs etc., whereas Technical Specifications constrict the focus and help business/developers to understand core areas related to implementation.

Topics to include in Technical Specifications Document

1. Business Requirement or Scope

First in the list. Sit with stake holders, hold meetings, ask as many questions as possible and log the business requirement clearly to kick-off.
Some of the scope examples are:
– Understand the Calculator Usage which includes the calculator modules for visitor classification and re-targeting such as inputs, tests, resets, edits etc.
– Understand Internal Search Usage in the portal to tailor improved experience to the visitors.
– Understand Application Funnel Flow across various user types to understand drop-offs and increase conversion.
Business Requirements will often be more general as they come primarily from marketing people who can understand functional areas more than being technical.

2. Key Performance Indicators

Once you have the Business Requirement, the next critical task is to derive Key Performance Indicators along with Variables and Events necessary for Adobe Analytics Tagging. This step is the key, more planning and preparation is required to build an efficient strategy, so take your time. If you are about to derive Variables and Events for Internal Search Usage, then Technical Specifications should focus only on the said Business Requirement and not everything related to website.

3. Adobe Analytics Variables Mapping

Simple but tricky step; Map the Dimensions and Events to the Adobe Analytics Variables.
Default Dimension or Prop or an eVar: Try to consume less dimensions. It is not necessary to create numerous dimensions since because it is required, a proper plan can reduce the need for the same i.e. Classifications might help to group/dissect the line items.
Events: Try to use more events. There are 1,000 events in Adobe Analytics, so don’t be a miser.

4. Server Call Methods

Make a note on the Server Call Methods used to capture the Dimensions and Events related to the Business Requirement. It can be a Page View call (s.t()) or Non-Page View call (s.tl()).

5. Variables Syntax [With Examples]

One of the key purpose of Technical Specifications is to define the Dimensions and Events Syntax for developers. Few often we would need to build proper nomenclature for the variables, but not mandate.
It is okay to capture the Internal Search Terms without any set Nomenclature, but if it is a Form Validation Error, we should capture both Field Name and Error Name together, thus proper nomenclature is must. Our examples should include both Syntax and Nomenclature (Optional).

6. Deployment Steps/Scripts

When you have a Adobe Analytics Developer, this is not essential, but mostly we work with content developers who didn’t know Adobe Analytics, which means it is essential for such situations. Both Page and Tag Manager editions are to be included. The document is sometimes referred to as a guideline by content developers whenever website changes occur i.e. Website checklist.

7. Triggers and Conditions

After defining the Syntax, Nomenclature (Optional) and Deployment Steps, triggers and conditions to be included. Triggers include Page Load, On Click, Mouse Over etc. Conditions will be mostly global or URL specific, but that’s not the limit.

8. Additional Configurations

If there are any additional configurations such as Processing Rules, Classifications etc., are required, can be logged as well.

9. Revision History

Must to include so that any architect can understand the document updates over the period of time.

That’s it, you are done! Thought of sharing a sample Technical Specifications but felt that it would be my limited view/template and didn’t want to influence your creativity. Either it be a DOC or PPT, just make sure you include the above and the rest is your choice! But if you are still keen to see a sample, subscribe and reach me at terrynwinteranalytics@gmail.com though the subscribed mail ID, will send you one.