Transitioning to Flashtalking’s Creative Manager – August 2016
During the summer of 2016 working on the Studio team, we were working hard on transitioning clients from the older Creative Interface to the newer Creative Manager. There were some differences in workflow, one of the major ones was starting a new Creative Library and uploading your first files. I created this short video in order to quickly address client concerns that were coming up in e-mails on a regular basis.
We could send this out and follow up with the client if they needed more assistance. Ideally, it was better to address concerns individually, but this allowed us to respond quickly, giving us time to set up a screen share if necessary, not wasting everyone’s time trying to pick a moment.
Creating a State Call in the Flashtalking API – August 2017
One of my responsibilities at Flashtlaking was to dig into some less used parts of the API and make them easier to utilize by surfacing a typical workflow and documenting necessary details to make the experience less daunting. When you don’t use something regularly and don’t have friendly documentation that tells a good story of its workflow – you typically don’t want to be the point person supporting this effort. My job was to figure out what that workflow would be and tell a compelling story of how and when you would want to use it. The State Call was one of those things.
Occasionally a client would need to track more detailed information from an ad, like if it were using some kind of geo-targeting to pass along a users zip code or general location. Or maybe we wanted to track what SKU product numbers were visible in a carousel and which item was clicked on by a user. In order to do this, we had to log that data as a string to a service that would pick it up and parse it into a report.
It was vital that the string and the actions were very specific and well tested before rolling it out live. Also, it was hard to test this without getting multiple team members involved (who often didn’t have the time), so any and all testing before bringing them in was imperative.
In the presentation notes and video below, I cover the details of this setup and how to test without being scared of this whole process. My job was to make this type of thing feel achievable by anyone.
One of the larger clients I supported at Flashtalking was Hulu. Hulu had an interesting setup as they wanted to create video ads but as they have a fairly robust CDN they wanted to save a little money and use their own network to stream the videos, but through the Flashtalking player in order to get important metrics. Typically this wasn’t allowed through the API, but we found a workaround.
In the time I was supporting this effort with various agencies building ads for Hulu, Flashtalking transitioned their tool for uploading and managing creative files from an older Flash-based system called the Creative Interface to a more modern HTML 5 tool called the Creative Manager. Along with this transition came some changes to the way the ads were set up. Below you can see the documentation I put together along with a screen share video I created showing the changes.
Flashtalking Studio Training – January 2016 – January 2018
Learning an ad-server’s API isn’t hard, just detailed. Creating a compelling story leaving customers with a “can do” attitude creates better results leaving all parties happy.
One of my responsibilities joining the Studio and Support team was to conduct training sessions with clients new to using the Flashtalking API. Ad Server API’s aren’t that difficult to implement, but they are detailed. With only an hour to cover all the basic integration points and the basic developer workflow from ad creation to QA and client approval, it can be tough to conduct a training session that doesn’t overwhelm the participant with details.
Typically one of these training sessions would be a rapid-fire barrage of facts referencing some minimal documentation which was in need of some love. Following a training, it was our job to answer questions through e-mail about details forgotten or missed. Depending on the client, this could end up being quite a bit of extra work.
One of the first things I did was try to get the documentation updated, which proved to be more of a long-term project. Instead, I turned my focus to developing my own support documentation that was shared before a training session. This document covered in detail the typical training session, could be quickly customized to suit the client, and easily expanded to cross-reference other supporting documents.
When the training screen share was scheduled, included on the invitation was a link to a public-facing Evernote document with detailed notes with starter files and screen captures of everything covered. We recorded the screen share and sent a link to the video in a follow-up e-mail along with links to any documents supporting questions that arose during the training session. With the detailed notes and screen share in hand, we created a level of comfort with the Flashtalking API giving our customers a “can do” attitude cutting down on unnecessary communication that ends up wasting everyone’s time.