How an iPlayer API engineer delivers features across platforms
API Engineers as Consultants in collaboration with user-facing product teams
iBL stands for iPlayer Business Layer — yes, we are ‘the API team’, but we are also the team that implements any shared business logic that affects iPlayer on any of the 3 key platforms (TV, Mobile and Web).
As an engineer in the iBL team, we’ve got great responsibility in maintaining a robust and resilient API. We are also very closely integrated with the audience facing teams to drive the product forward. We consult the teams on how the data works, and what impacts their decisions will have on the rest of the product.
Recently I have been consulting one of our audience facing teams on a new feature — from discovery to implementation, I wrote very little code and helped deliver a major milestone for iPlayer.
This is the story of how we go about embedding engineers as consultants in other teams.
iPlayer Product Teams
iPlayer runs on many platforms — we have the website, the mobile App on the Google Play Store, Apple AppStore (which includes Apple TV) and Amazon Store, and of course connected TV devices, set-top boxes and other syndicated platforms such as Virgin and SkyQ.
We have many product teams across all the major platforms from connected TV to Mobile to Web. All the teams are cross-discipline teams with engineers, testers, UX Designers, Project Managers. Each product teams are all consumer/clients of the API, the team I work in, called iBL. Kit wrote a nice post detailing the tech stack behind all of this.
iBL — The product API
A lot of user-experience defining features on iPlayer can be categorised as data-driven or UI-driven.
To give an example, guidance warnings on certain episodes. Some episodes have warnings about strong language or similar. The way this message is communicated to the user is primarily a UI feature, but the actual message is data feature — and data features like these are decided in iBL. Which episodes have guidance warnings, what the message is, all this comes from iBL, and we can change it. But any change we make to the data need to be understood by the clients.
In this post I will go into some detail about how iBL works with the platform teams, and other supporting engineering functions within the BBC.
The product question
The specific question we want to answer is: What impact does changing the promotions on the top have for a certain age range?
Specifically, we want to explore, deliver and measure the impact of a personalised experience for the ‘youth segment’ of 16–34 year old users who have opted-in to personalisation. This requires teamwork, not just from the product teams above, but also the editorial curation and strategy teams.
Why does iBL need to be involved in this to consult? Users sign on in the clients, not in iBL, so the clients can probably figure out the users' profile without help from iBL. But this is where it stops — the clients would need to know what a different age group means. They need to know what episodes are promoted, where the promotion comes from, how the promotions are scheduled. All of this is data. Data that is in iBL, data that is part of the cross-platform business logic.
However, iBL can’t just make the decision to serve another feed to the youth audience — we do not have the resources to analyse the best ways this feature works with the rest of the user experience. Getting a product team to look after this means there are UX, product, and data analysis resources to prove the hypothesis.
The Data and the product
As first step to a more personalised experience in iPlayer, we have spent the past year revamping how the homepage is assembled. We now have one GraphQL API that returns a highly personalised view.
This really is a change to be implemented in iBL. However, iBL is a team consisting of four engineers — the product managers are embedded in and managing the product teams. This is a product feature, and needs input from disciplines other than engineering — product, UX, editorial and our data analysts.
This is why we decided to ‘open up’ iBL to contributions from client teams — they know the product, the audience and the user needs, and we can facilitate this collaboration. The ‘iBL Consultant’ is born!
Consulting
As a consultant, our responsibilities are beyond code, and sometimes do not even include any coding at all. There are three main pillars:
- Supporting Discovery
This includes advising on what’s possible — client teams, including engineers, are not usually aware of the capabilities of the platform built by iBL. Working with the client team in workshops to define the feature and elicit requirements. - Technical Delivery
Providing technical support to the client teams — if it is a feature for which iBL provides a ‘starter kit’, say a new bundle based on existing feeds, the client team may decide to have it implemented by their engineers. Alternatively, we may decide to run a developer exchange of either an iBL engineer into a client team, or a client team’s engineer into iBL to pair on aspects of the feature. - Delivery/Project Management
The iBL roadmap is rarely empty, and iPlayer project managers need to keep informed about what is happening. As consultant, we manage prioritisation of any work relating to the feature within iBL and ensure deliverables are aligned across all platforms with the lead project manager for iPlayer.
It should be noted that, once delivered, ownership of the code lies with iBL.
The Youth Bundle
At the beginning of this project, the objective was to create a personalised homepage experience for 16–34 year olds, which can be A/B tested. The scope of the ‘experience’ was not yet defined. That’s where the discovery session kicks in! The Editor of iPlayer, the Editorial Manager, and me as a consultant make their way up North to create that definition with the Mobile product team, and their ‘Ada’ crew of engineers.
Since this was going to be the first time we are segmenting the audience in iBL, we wanted to keep it fairly basic. Some of the main questions we tried to answer:
- What is the experience going to be like?
Change the whole page? Add a new bundle? Modify an existing bundle? - How do we curate this new experience?
Is it all manually selected? Can we use existing data (e.g. channel, genre, category) to select the content automatically? Can it be semi-automatic where the editorial team can define weightings or priorities? How much effort will this be, both upfront in engineering cost, and to keep it running editorially? - What timeline are we operating on?
Are there any big events coming up? Are there any big releases coming up? - How do we build this thing?
Are we re-using existing feeds? Do we need new feeds? Who else do we need to collaborate with in order to deliver this? Does iBL need to do any work, or can the client team deliver this themselves? - How do we measure the impact?
Whilst we have A/B testing on certain platforms as Andy explained in a previous post, extending this to measure the same thing on all platforms equally is a bit more difficult.
There were introductions, hypotheses, post-its, a big whiteboard matrix, KPI definitions, edge cases and much more. The product team’s Business Analyst, Project Manager, Product Owner and Engineers, who are used to defining mobile app features and not data feeds, had to wrap their heads around a whole new world of workflows — and how it all works when you translate it to the website or TV devices. This is where I come in as a consultant from iBL, with experience of all that, and knowledge of the respective implications of the above questions on it.
Eventually, it was decided that we will modify the existing ‘Featured’ bundle with a specifically curated feed for the target audience segment. We also decided that we will run an A/B test on the new feature to assess any impact on key metrics such as consumption.
We also had to liaise with another team in the Online Production Systems group to create the new promotion destination in our editorial tools.
Since this was the first team we make use of segmentation in production, we also had to define an architecture for incorporating that in iBL — this was a discussion I had with the rest of iBL team.
Once all of that was ironed out, we could get started on modifying the existing editorial bundle. For that one of the mobile engineers, who works usually on Android in Java and Kotlin, joined us to implement this in our Typescript codebase.
We enabled the new feed earlier this year, and luckily I fall into the variant segment, so for me the Editorial bundle looks like this now:
Results and next steps
As for the feature, this was kept split for a couple of weeks, to observe the impact this has on audience behaviour.
Our data analysts then have some fun crunching numbers, and as outcome we have now rolled this out to the whole audience in the 16–24 age group only as this saw the highest positive impact.
We are also working on our technical capabilities to make testing a feature like this easier in the future. In the future, segments may not be as easily defined, or a lot more dynamic, so we are working to establish one common A/B (or even more variants) workflow for testing the impact of different bundles and promotions across all platforms which can be used as easily as the feature A/B tests we run on individual platforms already. This is a different challenge, and I’m sure there will be a different post about that at some point.
Engineers as Consultants?
Does it work?
For this feature, it worked. Why?
First of all, the product team didn’t just ‘look after it’, they made it their priority for the quarter. The product manager, BA, and project manager wanted to get results, and understood the need for iBL consultation and cross-platform approach.
The engineers in the client team were keen to get involved and work with iBL, and I was also motivated by the impact of consulting on this. In terms of UX, the team could design and effectively conclude their hypotheses of how it should work and feel.
Did anything not work?
We had some issues with the data analysis — the client teams do not have their own embedded data analysts beyond the BAs, so it wasn’t clear who was responsible for this. The teams are also split between MediaCity near Manchester, and White City in London.
Once this was clear, we could analyse the data and had a conclusion. But to improve this in the future, we are starting an iPlayer-specific data team based in London, ‘Data Force’, which you’ll probably hear about in another blog post. They have a logo and latin motto and everything..
I also believe that team and people dynamics play a big role — it needs to be the right feature, and it needs to have buy-in from the product team and the consultant. In this role, the consultant is working with people they may not usually work with, so it’s even more important to have something interesting to work towards.
Conclusion
I hope this gives an insight into how we tackle cross-platform collaboration at iPlayer, and that the life of a “backend engineer” in iBL can be a lot more exciting than one might think — Educating and Informing Discovery is very much in the BBC spirit as well.
If this environment sounds like something you want to be a part of, maybe there is a role open that suits you.
