What are SDKs? Why do we need SDKs to use any B2B SaaS Tool?
Learning outcomes of the article
By the end of this article, you will be able to understand what SDKs are, why SDKs are better than other integration tools like APIs, why coding your feature edits after integrating your SDK is better than using Visual Editors to redesign your experimentation websites, and the difference between server-side and client-side SDKs.
To start off, here is a clear and precise definition of an SDK: A SDK is an abbreviation for Software Development Kit. It is a kit that contains all the different types of tools users may need to use a particular service. For example, if you would like to use Hackle’s A/B testing logic and dashboard to view your user data, you would download the Hackle SDK or essentially plant the SDK to your very own code. Once the integration is complete, all the functionalities Hackle offers will be possible on your code.
What does an SDK actually look like and where does it go?
Yes, we get that it’s somewhat like a toolbox but what is the physical form of the SDK that is supposed to help developers?
SDKs are pieces of code called libraries that help a program play nicely on any type of platform. These physical codes called SDK essentially attach to the inside of your code for your website or app. Once they are attached to the inside of your code, these SDKs act as the individual, independent brain of your experiment. This brain concept is further explained in the section below when we compare SDKs to APIs.
Now the steps required to integrate the SDK vary immensely however with Hackle, it’s simply including pieces of code.
What does it mean to integrate your app/website to <Company XYZ> SDK?
By integrating existing apps you are able to not only integrate with the SDK but you are integrating your app or website with the capabilities outlined by Hackle.
We’ll use Hackle’s SDK as an example.
Once attached, your code is no longer dependent on the main Hackle server for carrying out experiments. The Hackle SDK attached to your code is capable of sending information regarding user events, carrying out A/B testing (with all the logic stored within the SDK), implementing feature flags (switching features on and off), and basically all the tools provided by Hackle. In other words, you bring the SDK into your service and use all the tools, features we provide with little to no latency because you technically planted the SDK to your code.
SDKs VS APIs
APIs are also known as Application Programming Interface, and you can think of them as the “passage” in which different programs, software, and servers communicate or talk to one another. Do you recall how SDKs were called the “brain”? APIs aren’t which means that if you were using an A/B testing software that required you to use APIs, they would still be dependent on the service provider’s logic in order to carry out user distribution and logic behind exposing what display to which user. This means that data and information exchange has to constantly occur between the A/B testing software provider and your server each time new traffic enters the experiment to decide which page he or she gets exposed to.
Some A/B testing firms offer APIs in order to carry out experiments on your website or app. However here are some limitations in simply using APIs to integrate and communicate between platforms:
- Takes a lot more time
- Response only takes place after each request
These limitations related to APIs are reasons why client companies may choose to plant the A/B testing software SDKs into their programs. An SDK can contain an API or tools to call an API. Think of APIs as the communicators that define how to access a resource. Resources can be SDKs to create an A/B test or the resources on the cloud where they can be retrieved from the cloud.
This is a common question we get: “How is your service so fast?” … The answer is that we provide SDKs that clients can plant into their code.
With SDKs, in a short amount of time, the SDK is able to figure out if the user should be exposed to A or B with minimal loading time without communicating back to the Hackle main server for the user distribution logic.
A/B testing on SPA Websites by Directly Editing Code (w/ SDKs) VS Visual Editors
Event tracking is difficult with SPA websites that are edited with a visual editor.
This is important as more and more websites are SPA-based (single page application) meaning that even when a specific button is clicked, the URL does not change.
On the surface, using the visual editor seems desirable as you are able to make easy visual changes on your website or app without writing any code. This means that if you want to experiment around with different button color changes, you, as a marketer, do not need to depend on a developer to deploy code behind different feature changes. However, there are also a few downsides. With visual editors, you have to face many limitations, especially with regards to SPA websites:
- Only a few types of features to experiment with (for example you cannot test out different algorithm changes with a visual editor)
- Complicated tests done on a visual editor will mess up the code
- Using a visual editor means that you cannot track events from such SPA websites as the URL doesn’t change
- Programs like Google Analytics can only track which URL was triggered but not individual events
- Using the same link and editing the display with new features with the visual editor
So how is user behavior data collected through visual editors (Google Optimize + Analytics) for data analysis and experimentation?
- They depend on a separate SDK focused on simply collecting data like Google Analytics.
- This means that people using programs like Google Optimize still need to integrate into Google’s SDK
- In reality, it is hard for Google Analytics to pick up all the information regarding user behavior like events and actions.
- Due to the fact that Google Analytics cannot be trusted 100%, this also means that calculations for A/B testing are not 100% accurate.
Difference between Server-side and Client-side SDKs
The difference is simple. It simply depends on the type of experimentation you want to carry out.
Now that we covered the advantages of adopting an SDK to carry out experimentation, here is the wide range of SDKs provided for each language. This means that whichever language you used to program and code your website our app, as long as you can find the language on the list, it is possible to integrate the SDK. Hackle provides both server-side and client-side SDKs. If experimentations are focused on testing out different user experiences, you may wonder why server-side experimentation is needed. However, for testing around with complex algorithms, simply using client-side a/b testing and SDKs won’t do the job.
From the chart below, you can assume the server-side language SDKs on the first column and the client-side languages (App and Browser) on the next two columns.
Use Cases for Server-side and client-side SDKs
Now here are some use cases for client-side testing:
- When you are distributing traffic into test groups to test changes on visual elements such as button color, layout changes, etc.
- When you need to track and send user events such as clicks, scrolls, etc. that are performed on the client-side without communication with the server.
- When the business logic is centered around the client-side
Here are some use cases for server-side testing:
- When distributing test groups to test changes to the backend system, such as improving the search algorithm or changing the recommendation logic
- When it is necessary to send a user event that confirms the status of the server, such as membership registration, purchase completion, etc.
However, the above scenarios are just examples and common areas in which the code codes for a specific feature or function in an app or website. In reality, it really depends on where you placed the code for a specific feature change whether that be on the client-side (front-end) or server-side (back-end). Hence it is technically possible to link both server-side and client-side SDK to support your wide range of experimentation needs.
Check out Hackle at www.hackle.io in order to start using our fast and reliable SDKs to power your very own A/B tests.
