~things that matter~

Category: Adobe Experience Cloud

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.

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.:

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!

Will Adobe Launch slow my site down?

Will Adobe Launch (or Dynamic Tag Manager – DTM) slow my site down?

Well, a better question would be how much impact would it have on the page speed?

And the answer is: so much as you want.

Adobe Launch (and most other Tag Managers in the industry) are just containers with bare minimum code/methods to make it work. Code weight can increase as teams keep adding more and more custom functionalities into Launch and execute additional actions.

You want A/B testing or personalization by Target on the page, and you want it to load asap to avoid flickers, you would load Launch synchronously. And then your “preferred” speed test tool will complain of synchronous scripts that should be done away with.

The paranoia can drive you to optimize the wrong things. I have seen customers worrying after a browser debugger said 47% of code in the Adobe Launch library appeared redundant! (it’s the interpretation to blame)

What this means is, the tools do not always know what you want. And you need to decide whom to trust.

There are numerous other things you should optimize to make your site faster.

The above used an example of Adobe Launch or other TMSs like Tealium or Ensighten/GTM. However, apply common sense to every other marketing script you deploy on the digital property. Does it need to load synchronously? Can the number of network calls be minimized? Can we move some of these server-side?

How it “feels like”: If you deliver a great user experience right from the beginning while loading additional content in the background, and even pre-loading the probable next pages, you should not be penalized. Modern search engines understand UX well and the page load factor plays a minuscule role compared to your site’s likeability.

Reduce the number of network calls, the number of SSL handshakes (look at WebSDK in place of standalone libraries from Adobe), and whatnot. It’s not the goal of this post. There are great resources on Google and elsewhere.

A certain large automotive company’s website, on average, took 11 seconds to load in a particular market (with low average internet speed). Care must be taken to reduce those painful calls for resources than just Analytics. In fact, we helped them remove the libraries and have bare-bone custom functions to send data to Adobe Analytics. Something is better than nothing. Unless you have a transaction to make on that site, you would not wait for content that you can easily find elsewhere.

By the way, have you explored Event Forwarding on the Edge from Adobe? Or similar features with your preferred vendor? There are smart ways to send in data in a standard format, and apply a whole lot of logic before sending them to their destinations server-side.

Deepak Ranjan Kar