The Case for Client-Side Omniture Implementations for Mobile

Any client-side data (details you cannot discern from the HTTP headers of the request to gateway) that you want to capture in the future, like the device’s screen size, color depth, image support, etc. requires development and testing. Any tracking of your own page features, like popup layers or JavaScript controls on a custom video player, require development and testing. There comes a point of diminishing returns where it becomes more cost-effective to switch to the AppMeasurement library because the logic has already been thoroughly thought-through, developed, and tested across devices.

The decision to make that switch depends on your business requirements. Right now your requirements maybe simple and your apps consist of simple pages. If either get more complex you may require client-side code.


Server-side tracking gateway pros:
1) One central code base to upgrade or fix to correct all mweb and mobile app tracking issues at once.
2) Client-side code is minimized to avoid technical differences and limitations across thousands of mobile devices. If you do enhance the client-side code you’ll have to test that it works on all devices.
3) Client-side code is minimized, which reduces page load time.

Server-side tracking gateway cons:
1) Any user interactivity that does not result in them loading the next page is not tracked without installing client-side code to handle that interaction and make a call to the gateway. This means developing server-side logic that has to be tested across all mobile devices.
2) Server-side tracking typically doesn’t account for cookie concepts, like persisting values for use on later pages, or counting the page number of the user’s visit.
3) Testing the data of sever-to-server calls is difficult. Drew and Ajay are discussing exposing details of log files already dedicated to the SiteCatalyst calls. Adam needs this to validate installations and troubleshoot defects.


Data points/features that cannot be obtained/achieved without client-side code:
* You do not need the AppMeasurement libraries for these but the library does handle them out-of-the-box

Device details:
- screen size
- color depth
- audio/video support
- image support

App usage details:
- Installs
- Upgrades
- Launches
- Crashes
- App ID

User interactivity:
- Click map / heat map
- Any clicks that don’t go to a full page, including file downloads and exit links
- Form error details, such as which field contained an error (assuming that you don’t handle form validation server-side).
- Custom video or audio player controls
- Slideshow controls, carousel scrolling
- Cookie-based tracking, like counting the page number (useful for identifying entry pages), or persisting values for later pages.

Omniture ClickMap and Mobile Sites

ClickMap will not function without the JS library (the s_code.js file) running on the page. ClickMap relies on the click detection built into that file and sets and retrieves cookies as the user goes from page to page. Some mweb sites do not include the s_code.js file, but instead rely on the mobile gateway to send calls from the web servers to Adobe's tracking servers.

You may come across other features that don't work with server-side tracking. Some features you can replicate to some degree by recreating the logic in your server-side code. But, some will require JavaScript to capture user interactions. If you are interested in recreating the logic within the mobile gateway, clearly define your business requirements. You may find that you don't need to replicate the visual overlay ClickMap provides. You might just need to know which links are clicked the most.

The AppMeasurement library is the way to go, be it JS, Flash, or for mobile apps. Server-side calls are limited and force you to recreate a lot of functionality.

Thanks to Adobe Consulting for this information!
Adam Berlinger