We often get asked to explain the difference between Transmit’s Journey Player and SDKs used by other vendors, usually something like “Isn’t your Journey Player just a fancy marketing term for an SDK?”
Granted it is a marketing term, but not just to make it seem fancy. It is used to explain something that’s a lot more than just a series of SDK code libraries.
The Journey Player uses an SDK approach to integrate into applications, however that’s where the similarities end. Once in place, the Transmit Journey Player standardizes identity and access elements across the entire infrastructure, adds identity logic, and drives the user experience through its own UI.
Instead of command after command embedded in application code to manage processes across an array of device and point solution SDKs, the Journey Player handles all of that and then seamlessly returns control to the application.
The real power of the Journey Player is its ability to consolidate point product SDKs and APIs, including native device elements for querying device parameters. Instead of having to change code to add or remove logic to support changes to SDKs, the Journey Player handles that automatically via the centralized Transmit Server.
For more information you can watch this short video of Craig Currim, our VP of Customer Solutions and Systems Engineering presenting the differences between the Transmit Journey Player and traditional SDKs.