Tangiblee recommends this integration as it is utilized by 95% of our retail clients. With this option, the Tangiblee team does 99% of the integration. Just add a Tag to the website and you're done. Tangiblee will provide the client with one line of code (the Tag) that tailors Tangiblee to the current PDP layout and ensures Tangiblee's CTA is shown on relevant PDPs.
Tailoring Tangiblee to the PDP of the client is done via a mapping code script (aka tangiblee-mapper.js). The Tangiblee team will create the tangiblee-mapper.js and maintain it for the client in the case of Managed Integration. The Tag created for the client is a wrapper to the tangiblee-mapper.js that loads from Tangiblee CDN the tangiblee-mapper.js bundled with the Tangiblee API script (tangiblee.js) into a tangiblee-bundle.min.js.
Tangiblee recommends placing that tag in the same place where the other Javascript tags are added to the page - it may be the end of the <head> or <body> section. If Tangiblee tags are added via Google Tag Manager (GTM) then GTM manages that automatically.
In some cases, clients need more than one Tangiblee Tag, for example, one Tag for the production website (PRD) and one Tag for the staging website (STG) each need to show a different configuration of Tangiblee. To support multiple Tags for one client, each with a different configuration, each Tag is set with its own revision. The client version is the last folder on the path of the Tag script, as you can see in the example below, the revision is revision_1 which is the default revision.
Below are a few examples demonstrating how Managed integration works on different use cases using Tags each with its own revision.
This example and explanation covers the typical use-case of using Tangiblee Managed Integration. It is usually done when integrating a single Tag on the Client’s website (PRD).
This demo link of Tangiblee Managed Integration has the default revision set to a Tag: revision_1
As seen in the example link, revision_1 is part of the path to tangiblee-bundle.min.js. It is a default version that the Tangiblee team will provide when using Managed Integration on a given type of PDP.
[.good]When a client plans to roll out an update to the PDP code, it is important to notify the Tangiblee team & provide Tangiblee with a link to the STG or DEV environment prior to deploying the update. In notifying Tangiblee ahead of time, the team can update the tangiblee-mapper.js, if needed, and test it on the new PDP to ensure continuous service on PRD after rollout.[.good]
If a change is detected by the Tangiblee team, we will work as quickly as possible given our team workload. However, this is not a 100% fail-proof process and the updates made by Tangiblee may not reflect 100% of the changes made by the client.
[.bad]Therefore, we strongly recommend that you update the Tangiblee team every time you make changes to your PDP code, structure, or layout.[.bad]
Below are the highlights of the configuration example above, and the Tag:
[.bad]Please note: this is not your Integration Snippet, but an example for the sake of this guide. Your Tangiblee point of contact will share an Integration Snippet specifically for your website during the Onboarding Process.[.bad]
The classic use case for using another Tag with a different revision is for a new website or a new PDP design, typically on the staging environment (STG). In that case, Tangiblee can provide a Tag with a new revision for the STG to ensure each environment has its own configuration.
This new version will have a newer revision_X param in a path to the tangiblee-bundle.min.js file, as you can see in the Advanced Use-Case Managed Integration - In this example, the revision is set to revision_2.
Below are the highlights of the configuration example above, and the Tag:
