Life & Tech

~things that matter~

Secret Sauce to (implementing) Adobe Mobile App SDK

To be specific, the Experience Platform Mobile SDK, at this moment, until we have another round of renaming!

There were countless instances of folks (include me) running scared of handling a mobile app SDK implementation. Mostly because it felt like writing rocket code; and all we could validate – independently – was like a black box.

Here are some words of wisdom (for a consultant) I gathered through my 9+ years on this:

Never speak implementation without a developer in the room. Say “I want the developer”. As a consultant – everything you say can be and will be used against you.
Keep 2 small goals:

  1. Let the dev include the SDK per documentation, and build without errors.
  2. Get the app to make “any” successful call to Adobe servers.

That’s 80% of the war won. You now have the confidence to guide folks through the rest.
This works, every time, every technology/wrapper/platform.

Protected: Web SDK worth it?

This content is password protected. To view it please enter your password below:

Blindly Trust Your CMP (Consent Management Platform)?

Bombarded your website visitor with annoying pop-ups asking to accept cookies? And you thought the consent management platform (CMP) was doing great?

Things were almost always the same, every time I got involved in a CMP vs. Adobe Experience Cloud situation.

Though the CMPs do a great job helping websites manage the collection and storage of user data by obtaining and storing user consent, I would not bet on (just) them. Especially when it comes to compliance and consequences.

Most often your CMP vendor helps present a pop-up or banner asking users to agree to the site’s privacy policy, cookie policy etc with an option to go granular in terms of selecting what cookies would be okay and what would not. And, as you might know, the preferences are usually stored in a cookie for future visits.
Would you trust that cookie? Or even the JavaScript that pops up the banner? Depends.

Client-side tech is prone to accidents and environmental factors. Whether mentioned in Murphy’s Laws or not, client-side tech does fail. And so do the banners, cookies and whatnot.
To top this up, there are “intelligent”, “automatic” features by various vendors that claim to detect and block network calls to endpoints until (the above) consent is granted for the respective categories. What you might not have noticed is that their documentation also says the tech is not foolproof (i.e prone to failures).

I am writing all this because we had been solving these problems all this time. Techniques employed by some CMPs fail to understand certain types of trackers and fail to detect certain network calls being made. In fact, when pointed out, a CMP rep. himself explained why their detection techniques were “dumb”. And did I tell the auto-categorization by the CMPs is something you must manually review? You should.

In short, your website may still be collecting data without consent or sharing user data with third parties. What you can or cannot (or shouldn’t) do is often subjective, and best handled by business goals and security guidelines. However, assuming consent granted until your CMP says otherwise, or leaving the responsibility fully with the CMP can end up being painful (and expensive).

What do we do, you may ask. “allow none” as a default behavior for trackers may be a safe approach. Then let the CMPs evaluate what can be allowed based on consent. For Adobe Experience Cloud products, as an added layer, you may want to explore the consent/privacy options with the Visitor API.

Long Live the DMPs

I wish I could say that.

Traditionally DMPs have depended on 3rd-party cookies. And the phaseout of such cookies has almost crippled, if not killed, the products. Approaches will still evolve and remain relevant – may not be in their current shapes and forms.

Let’s take the example of Adobe Audience Manager (or AAM as we fondly call it). Just like most other DMPs, AAM relies (ed) on a 3rd-party cookie set on demdex.net. And the loss of that cookie indeed takes away a large chunk of capabilities around it.

As 3rd-party cookie support has dropped drastically, and the deadline from Google/Chrome is fast approaching, what will a DMP do?

1st Party Data: That is, your (business owner’s) own data. DMPs are mature enough in leveraging first-party data that you know about your visitors/users. If you are aware of Adobe Experience Platform (AEP, the CDP) you would already know how much we all long for quality first-party data. In fact, that fine line between CDPs and DMPs is getting blurrier as we speak.

Walled Gardens: Using just your own first-party data will not justify why you had invested in the DMP in the first place. Probably this will give rise to options where other publishers are willing to share their own first-party information via the DMP. However, this appears to be far lower than what you would have done with a data marketplace without the current (and future) restrictions.

Things such as AI-driven lookalike modelling will still be able to deliver value. I will not be surprised to see Audience Marketplaces flourish with collaboration and sharing between organizations, greater than ever before.

Having said this, I am equally anxious as you may be, to see how the future unfolds.

Protected: Target On Top

This content is password protected. To view it please enter your password below:

CSP for Adobe Experience Cloud

There have been quite a few questions from across our Experience Cloud customers on handling CSP for the products, mainly Adobe Analytics and Adobe Target.

If CSP is something you are hearing for the first time, let me simplify: There are some Adobe domain names you should add to a Content Security Policy (CSP) on your website if you use these solutions and have tight security policies.

Allowing these domains lets visitor browsers that access your site make those important calls to Experience Cloud resources that you use.

Our documentation covers CSP recommendations for the various solutions separately. Feel free to review them here and here.

These documents tell you the domains that need to be whitelisted for your website to communicate from a browser. Few things you need to keep in mind:

  • unsafe-inline” can help fix the CSP errors. However, that is UNSAFE 🙂
  • A nonce-based solution would be required for Adobe Launch.
  • Launch must load asynchronously for the recommended approach to work. Technically, if you feel adventurous, you may be able to make a synchronous deployment work equally well. Again, neither a recommendation from Adobe nor would I be responsible should anything break.
  • While Launch would work with the nonce-based solution, you must take care of Adobe Target pre-hiding and flicker control code (outside of Adobe Launch) separately (i.e. allow them somehow).

I feel that is enough instruction for someone who knows what CSP is. You can see some (not-so-elegant) csp demo pages here.
Do look at the CSP HEADERS and/or META Tags, and the custom message I am printing in the developer console, e.g.:

Where Went the Old Blog

If you visited this site a few years back, you must have seen something like this.

There was random scribbling under Ideas, and a relatively young photo-blog under LivePixels. The content (at least most under Ideas) no longer appeared relevant; and hence, was replaced by the placeholder for about a year or so.

Meanwhile, this website has been increasingly used as a playground by myself and colleagues alike. Quick and dirty demos (mostly for Adobe Experience Cloud products and web tech) have been hosted here. Direct links to those demo/test pages should continue to work as usual.

I am going to re-upload the personal content on Blogger/WP.com platform soon. Yet to test the migration mechanism.

It would be fun looking at how your thoughts evolved over the years!

Protected: Do you audit your TMS (Tag Management System)?

This content is password protected. To view it please enter your password below:

Cross-Device? Yes Please

Wondered what to do when the only approach to connect cross-device behavior was by using a Custom Visitor ID (read login ID), and then your Adobe consultant strongly discouraged doing that?

That legacy approach of using a Custom Visitor ID has been in the crossfire between the legacy way of getting things done and the modern (and more futureproof) approach of connected journeys and activations using ECID.

What’s wrong with the legacy approach – you may ask. Sure, that was a solution built-in with a lot of historical burdens, worked well with Adobe Analytics/Omniture as a standalone product. However, that restricts you from getting the latest and greatest benefits from ECID, the future-looking identity solution that has been and is only going to be more closely integrated with Analytics and the Experience Cloud features.

Here comes CDA – Cross Device Analytics, to give you a view of user behavior across devices should you be able to provide a unique identifier tracked in Analytics. It’s dynamic and can be applied retroactively. You do CDA in a virtual report suite, and mostly do analysis and reporting based on that.

What if I want to connect journey components that do not have a common identifier? Read up about CJA (Customer Journey Analytics).

Get rid of that s.visitorID today!

Some Adobe Analytics magic in PDFs

[Update: 2020-04-04: We now have a productized solution via a client-side PDF rendering engine, DCViewSDK. I have removed the technical details of the custom solution from here.]

Back in South Africa, our customer wondered how some companies claimed to be “magically” tracking what you did inside a PDF document. And they asked why hadn’t Adobe Analytics got something similar; especially Adobe being the PDF pioneer.

The company was interested to understand the consumption of their clients’ PDF brochures and targeting those who reviewed the stock price (page).

Now, ever wondered how it might feel to be able to understand what content inside that beautiful pdf brochure people are looking at?

  • Send a personalized message to a potential customer who read about a new offering in the brochure.
  • Figure out if a piece of info out there may make more sense at a prominent location on the website real estate rather than buried deep within a voluminous pdf.
  • Or even for the designer, is there a piece of content that forced users to zoom in?

The Problem

You are not alone. PDF Analytics or document analytics in a broader sense had been a path rarely traveled. There were not a whole lot of options for accessing a URL or data collection over the internet. That kind of restricted Analytics efforts on downloaded documents.

The Solution

However, as most browsers are now capable of rendering PDF documents, the question becomes simpler. How do we add Adobe Analytics client-side technologies into the content that’s already sitting there, in the browser, in plain HTML?
The answer is a JavaScript-based PDF parsing and rendering engine. Once the PDF document is rendered in the browser and you get access to the DOM, you can very easily deploy Adobe Analytics and the Launch Tag Management Solution. With minimal coding, you can capture the page number and interactions therein: zoom, search, select, copy text, and print to name a few.

The initial solution leveraged a good 3rd-party library for rendering PDFs. However, a lot has changed after that, and we now have a great rendering engine called the View SDK from Adobe. Adobe Analytics integration comes pre-built.
At this point, I would rather suggest you review the widely available documentation and public posts (including this one I wrote) on the topic.

PDF Analytics may soon become the new norm. The great thing is that it can be done in a Non-Destructive way. The plugin is easy to deploy and manage! Please, try it today!

Page 1 of 3

Deepak Ranjan Kar