Yuma 4×4

Media and Communications

Google Ads API Workshop – Spring 2019 – Migration Planning

Google Ads API Workshop – Spring 2019 – Migration Planning

we’re going to talk about the faces of migration,
some of the similarities and differences between
the old and new APIs that affect migration. And we’ll give you some
sample plans of migration that have been used
by other customers. So in terms of phases– as I mentioned at
the beginning, we’ve been in beta for about a year. And your experience
is going to be different than
other customers who have migrated
because you’re going to have to make some
important choices about what are the services you want
to migrate first but also how you want to refactor
as you’re doing migration. First of all, in
this session we’re going to talk about how to
plan for your migration, how to scope for it. And in the last
session this afternoon that Knack is going
to be doing, we’re going to be going more
into the technical depth about specific services
and specific changes. So in the first step about
familiarizing and planning, you’re really doing that
today in that you’re getting familiar with documentation. You’re understanding the
key technology differences, and you’re making
your first call. So by the end of
today, I’m hoping that everybody in this room
will have effectively completed this first step in migration. Where is the documentation? Now about the documentation,
it’s interesting. We’ve done some user studies,
and pretty consistently if you’re experienced
with the old API, you want to start
coding right away. And you say, oh, I know
all these concepts. I know how to use the AdWords. I’ve been using it
for a number of years. And you want to
start writing code. And from our usability
studies, that’s really not the most
effective way to do it. It’s much more effective if you
understand some of the concepts beforehand,
understand especially some of the troubleshooting
areas and the migration areas. So I’m not sure if you’re one
of those weird people like me who likes to read the
documentation before you start using something
you just bought. But we do recommend
in this case that you spend some time getting
familiar with it, especially about the
migration concepts. So we mentioned this a
couple of times already, that the authentication
credentials are the same. The only difference is
this login customer ID that we just talked about. And this came up in
one of the questions, so it kind of precluded
this is that there’s really a single view of reality here. Irrespective of
whatever mechanism you use to make
changes to your ads accounts, they’re
going to be reflected in all the other places. So that’s hugely beneficial. We’re not migrating databases. We’re migrating interfaces here. So some of the key differences– well, the first
obvious difference is the query languages
are very different. So we’ve gone through that
a couple of times already. The field names are different. So in the AdWords API they
are separate field names. Here, the field
names are nested. So you’d have, let’s say,
AdGroup dot whatever. In terms of retrieving
values, there were a bunch of different
services in the AdWords API for retrieving values. Here, there’s really
the GoogleAdsService, and the GoogleAdsService is the
best way to retrieve values. While there are APIs for each
of the individual resources and you can do a GET, the
GET is really not the way to do that because
it’s really limited in terms of performance. You really want to
use the AdsService and make regular
queries [INAUDIBLE],, and that way you can
go service by service or you can make more
broader requests. In terms reporting,
how many people here are reporting only users? So there’s a category
that’s reporting only. For the reports that
you are already doing, there are separate services
for separate reports, like the Click Performance
report, for example. There are no more separate
reports in the new API. It’s only through the
single query language and the single ad service that
you get all your data back. So that should simplify things. But in terms of
migration, if you have a whole bunch
of different reports, they are going to be merged
into one way of doing things. So right know on
our website we don’t have a lot of examples on how
to take the popular reports and migrate them, but we
did do a detailed analysis, and it turns out about
six of the reports represent 90% of all
the report usage. So we’ll be providing examples
of those most common reports and how to do the
exact equivalent in different languages. And I believe you had
a question over here? AUDIENCE: So the
report types, you think the campaign [INAUDIBLE]? DAVID WIHL: Yeah,
so there, there’s even no separate notion
of reports in the new API. There isn’t a report service. AUDIENCE: Just read
whatever column [INAUDIBLE]?? DAVID WIHL: You just read
whatever metric data you want and whatever attribute
data you want. So there is no notion
of reports anymore. It’s not a distinct entity. So on the website, we do have
a very detailed list of report mappings, and it goes
in excruciating detail about what were the old fields
and what were the new fields. And we’re going to only
continue to elaborate that reference-type information
into more pedagogical information that you
could use to say, these are the reports
I use and just give me the code on how I can do this. So if you have particular ones
that are most critical to you, let us know about that, and
we’ll try and prioritize those. AUDIENCE: You have some
sort of documentation for which fields are
compatible or incompatible with each other? DAVID WIHL: So when
you say fields, do you mean the mutable fields
or the reporting fields? AUDIENCE: Reporting. DAVID WIHL: So that’s
already on the website at the previous link. So if you go here
and you bring up that link to migration reports,
it goes through all that detail already, and it was a lot of
effort to put that together. So it’s there now,
but it’s really more of a reference form. It’s not very pedagogical,
but it’s there. So using the sample code, we
have about over 30 examples per client library today. In the AdWords API,
we had 90 examples. So we don’t have sample parity
yet between the two APIs. There’s a question of
whether we’re going to have full sample parity. And the reason for that is that
the samples, if you used them, tend to be very narrow. They tend to show how to use
one very specific thing in one very specific service. And we’re going
to try and provide more generalized samples. So one of the samples
we’ll be seeing– we hope to have it out
by the end of March. It might be the
beginning of April– is to walk you
through a migration through the five-step stages. So if you’ve used like
the batch job service and you create a budget and
a campaign and keywords, it shows you how to take
it from a pure AdWords API version of that and migrate
each of those services separately into the new Ads API. And then by the end,
after five steps, it’s completely in
the new Ads API. So that’s really what
we’re encouraging you to do is to migrate piece by piece. So that’s the first of
other samples like that. If there are particular
samples you’d want to see or particular scenarios
you’d like you see, that would be great feedback
to help drive what other things that we’d produce for you. In this afternoon’s
session, we’ll go through one of these samples. And the idea is that you go
back to your offices afterwards and you go through some
of the other samples to get familiar with it. So the second phase
is after you’ve done your initial understanding
and your initial actually getting it working is to
scope a detailed plan. And for that what’s worked
with other customers is to do a proof of concept. Now the main reason for
the proof of concept is not just to try out the
API in a more detailed way, but it’s to
understand what areas you need to refactor in
terms of your application. So we’ve talked
about transactions as being important. That’s probably going to require
some refactoring on the part of your application. We’ve talked about
reports being different, and that’s going to
require some refactoring. Another aspect
that we haven’t yet talked about which we’ll
discuss this afternoon is that when you get
values back in a report, those are all mutable. So when you used the
AdWords API previously, you’d get back
results from a report, and you couldn’t do
anything with those results. Now when you get back
results you can say, oh, I got back these
attributes and metrics. I want to set the field mask. Just change this attribute,
and then send it back up. So those things
are all things that are aspects where
you have to decide, do you want to do a small
amount of refactoring or more significant
refactoring to take advantage of these things? Now on the website we also
have a further detailed article about why you should not
be doing some kind of shim. You may think, oh, I have
all this existing code. I just want to
build a translation layer between the old
API and the new API so I don’t have to change
all these different places in my code. And that has proven
to not be a good idea. And we go through in detail
in the migration section about why we think building
a shim layer is really a suboptimal way of doing
it and ultimately will cost you more than doing
a more native migration. So in terms of the planning and
detail, during the second phase what we think works
well is to identify, what are the dependencies
of your different services? How do you want to break
apart your application to say this service I can move
easily now and kind of get started and start using
that in production, and then when I
start getting to more of the core piece
of my application, how do I want to figure out
what are the dependencies and what are the sequence
of the migration? And the idea here is that you
are doing it part by part, and you’re not doing a
wholesale monolithic migration. We think that that’s
the safest way to do it, and we’ve purposely
designed it so that you could do this kind
of incremental migration and that it doesn’t require
one day of switching everything over from the old
API to new API. But over time you’re going
to migrate piece by piece. Are there any
questions about that? Do you think that’s a
reasonable way to do it, or do you plan on doing
it more monolithically? Any thoughts either way? Makes sense to do
it piece by piece? Anybody see any risks of
doing it piece by piece, any concerns they have about
doing an incremental migration? Well, again, this is something
we’d love to discuss with you. And during the break or
any of the other sessions, if you want to go through this
a little bit more in-depth and explore some
ideas with us, we’d be happy to talk about that. So let’s do an example of
a reporting-only migration. It doesn’t sound
like there’s anybody in this room who’s
reporting only, but this will roll
into the next slide. So here’s an example of
moving about 15 reports over. So some of the reports or some
of the views, to be clear– the report being an
AdWords term and a view being more of an Ads API term. [AUDIO OUT] are
semantically the same, so there’s a very
close similarity. But some things
have moved around, and they’re not
in the same place. So some of the metrics that
you thought were in one place are not there anymore, and some
things have been broken apart. And the reason we did
that is because we wanted to make this a better
architecture for the next 10 years. So some things that
had baggage because of where they were
kind of thrown in we’ve cleaned up and fixed up. So reports that are
semantically the same we think will take about two days of
developer time per report. Ones that are
semantically different will take about three days
just to find where things are. And we’re going to try and
mitigate that by better samples and by better documentation. But it’s still
going to take time to figure out, oh,
this thing was there, but now it’s no longer there. It’s in this other place. Or this thing was
split into two places, or this thing was combined
from two different places into one place. So things have moved around. Looking at a
full-service provider– so the bottom line
is kind of rolling in from the previous one
where it’s about 100 developer days for reporting migration. This is how other customers
have broken out their migration for the full-service piece. And in their case
they’ve split apart what is the upwards migration. What was the upload
versus the download? What is the sync of pulling
information from the Google Ads API to your local application
and then doing the mutates back from your local application
to the Google Ads API? Now there’s obviously
some overhead of running both concurrently. There’s time you have
to add in for testing. There’s time you have to
add in for refactoring. And the refactoring, that
second-to-last line here, probably has the
highest variance in the room in the sense
of your individual choices are going to depend
on how much you want to do work upfront to
move to the migration now with refactoring
application and how much you want to do down the road. So do you want to start now and
make it pretty close and not maybe take advantage of
some of the atomicity or some of the other features
that we have in new API but then plan to
refactor over time, or do you want to
go more full bore and take advantage of some
of these things today? So these are just
general guidelines. It’s just kind of
one perspective, but it gives an
order of magnitude. So it’s somewhere around 700,
maybe a thousand developer days is what we estimate
to do the migration for a full-service provider. Some customers have come
back with 1,500 days because they want to do a much
more extensive refactoring or they’re being much
more conservative in their estimates,
but that varies. The ballpark we generally see is
about a thousand developer days for the complete migration. So is that a big number? Is that a shocking number? Is that a reasonable number? Yeah? AUDIENCE: I have one engineer. DAVID WIHL: You
have one engineer. AUDIENCE: So you’re
putting me out of business. DAVID WIHL: Well,
we’re not intending you to do that, obviously. So what I would do
if you have limited resources is that
you start developing new stuff with the new API now. And then as you grow and as
you advance, you migrate over. Any new features you add, you
build them using the new API so you won’t have a
migration problem, and then you look
back and figure out– and you gain experience
with the new API, and then you figure
out how you’re going to migrate the old code over. So if you have one
engineer, they probably haven’t spent huge amounts
of time building this so far, and it may be easier to migrate. And the other thing
is that you have certain efficiencies
with one person because there’s
less coordination. There’s less debate and
dialogue about how to do things. So I know in my own experience
when writing code solo, it’s probably significantly
faster than writing in a team. But you don’t have necessarily
difference of opinions and maybe a broader scope to it. So we’re trying to mitigate it. We’re trying to give you
realistic expectations. We obviously don’t want to put
you out of business doing this. We’re trying to get you to
plan ahead early for it. And if there are specific
ways we can help accelerate it by better samples, better
documentation, please let us know and we’ll try and
help out with that. And this is a ballpark
for a very complicated full-service provider. It may be that other
people are able to migrate in significantly
less time than that if they know their
code base very well and they’re working
solo or a small team. Are there other
reactions to this? Is this much less
than you expected, much more than you expected,
about what you expected? AUDIENCE: I’ll have to talk
to my engineering team. DAVID WIHL: OK, all right. I think you’ll only
get a sense of it when you start doing that
first proof of concept and start playing with it. This may be conservative
compared to– it’s not necessarily
linear, right? As you start using the
API, initially there’s this learning curve. And then as you get
more familiar with it, things are going to
go faster and faster. So you may not decide to put
that much time into testing, for example. You may have much lower overhead
to run both APIs concurrently. So this is just kind
of a general ballpark, and again, your mileage is
definitely going to vary. That was a great discussion. So the last portion
is about code, and this is where you’ve
done this planning. You’ve started to figure
out the dependencies, and now you’re
starting to actually go much more in a coding phase
and moving things service by service, and that’s going
to be covered in that session this afternoon. The important thing here is
that to ease this migration, you should be using
both APIs concurrently, and you should be able to do
this in a fairly smooth way rather than this kind of
violent, aggressive way of making wholesale changes
one after the other. So in summary, so
step one is today. Familiarize and plan. Make your first call. When you go back is
to scope this out. Do it more in-depth. Do a proof of concept. Decide how much effort you’re
going to put into refactoring. Decide how you’re
going to break up this migration into
what services make sense for your specific needs. And then repeat that n times so
that you’re migrating service by service and that you
can maintain stability and that you can
adequately address the time in the
migration period. In terms of resources, this
is the usual resource slide. We’ve highlighted a
couple of things that are specific to migration here.

Leave comment

Your email address will not be published. Required fields are marked with *.