One-Time SDK Integration: Minimizing Front-End Involvement

[JeanBaro_]

Hi everyone,

I’m hoping to get some guidance on integrating WebSDK and Mobile SDK into our front-end applications (Angular, React.JS, and React Native) in a way that reduces the need for ongoing support from our front-end  development teams.

After the initial integration, we’d like to know if it’s possible for the AEP team to manage future changes to data collection (like including new fields or data points to be collected) without needing much involvement from the front-end teams. Essentially, we’re aiming for a setup where the SDKs are configured once, and any updates can be handled by the AEP team alone.

A couple of questions on this:

1. Is this kind of autonomous setup achievable, where the AEP team manages adjustments without developer input?
2. Would setting it up this way require a significantly more complex initial integration compared to other approaches?

We’re trying to find the right balance between a streamlined initial setup and minimizing ongoing dependencies for the front-end teams.

Any advice, best practices, or potential challenges we should be aware of would be really helpful!

Thanks a lot for your insights!

[bjoern__koth]

Hi @JeanBaro_ 

well, of cause an initial solid data foundation / data layer is key for less future development on the frontend side.

In general, your AEP/tag manager people can only pick up what is there on the website. Meaning, if you ever need additional information that is not accessible through JavaScript, it will have to be provided by the underlying website (rather backend data made available in the frontend).

Though I typically strive for an event driven data layer approach where the website lets the tag manager know what is happening, when it's happening. Just since it knows best if all data for a specific action is available. This usually comes with a little bit of extra work for the frontend developers, but typically they create a small library function for triggering an action, so that once implemented, it is not really much effort for them.

Huge benefit is, that the data quality is way better and you have a more sustainable approach than having a Launch rule based on a CSS selector that may change on a couple of months, worst case without you even noticing, leading to data loss until it is detected and fixed.

Bottom line: try to find a balance between what you can easily derive from the page yourself like a document.title, and what may be safer to get from the developers instead.

Hope that helps 

[JeanBaro_]

Thanks, that makes total sense!

If the additional information we need is already available in the DOM or the React Native UI, is there a way to avoid going back to the front-end teams to adjust or configure the WebSDK? Our goal is to minimize dependencies and reduce the need for new releases, especially when Marketing requires newly added data that's already in the front end.

I understand some data might still need back-end support, but we'd love to streamline the front end part as much as possible.

Appreciate your insights!

[bjoern__koth · Accepted solution]

The Web SDK is just a library you will likely play out with your tag manager. The tag manager itself will instruct the Web SDK to send data to Adobe.

So, there is no direct integration of the Web SDK if you use your tag manager to do so. Also, essentially the Web SDK functions in the same way as your classic Adobe libraries like Analytics and Target. It is indeed replacing the legacy libraries

So, the efforts for your frontend team should not increase through this library but merely stay the same