February 18, 2020
Personalized Customer Loyalty at Scale with DSW (Cloud Next ’19)

Personalized Customer Loyalty at Scale with DSW (Cloud Next ’19)

going to be covering today, a couple different points. I’m going to walk you through
the loyalty history of DSW. It’s been an important
part of our brand and our business
for quite some time. And then we’ll
jump into the asks and needs, what the
business came to us to do, and how we were going to move
their loyalty program forward. From there, I’ll turn it over
to Cam, my lead engineer, who will talk us through
the choice on how we landed on Google Cloud as well
as our implementation, so what our lifecycle was
getting into the cloud, what it’s doing for us, and how
him and his development team are able to deliver
on a day-to-day basis. And then at the end, I’ll
come back in and follow up with what it looks like
today, how we’re implemented, how we’re moving forward,
and what’s next for us as DSW and designer brands. The history of loyalty– again, DSW has been around
for quite some time. Originally, just
a brick and mortar retailer, like most others. The loyalty program
actually started back then. In the late ’90s, they actually
launched the first loyalty program. It was called
Reward Your Styles. It was actually sourced and
supported outside of DSW. In 2004, we brought that
in-house, and then quickly thereafter, in 2006, we
actually launched DSW Rewards. DSW Rewards, as you can
see from the timeline there, while it
launched in 2006, really didn’t have much
change or impact to it until we launched VIP
just this past September. We did implement over the course
of time there the experience on our dot-com profile. We did implement that
in 2009, but when we did that, that was
a customer’s choice, so we still had people that
could have a dot-com presence, but not be part of our loyalty,
and it added that confusion to what they were
ultimately doing. You had people that
thought they were in loyalty, people that didn’t
think they were in loyalty. So in 2013, when we
rebranded and replatformed our dot-com profile, we enrolled
everyone into the profile. When you go to DSW.com or if you
give us an email in your store, you’re instantly into
our loyalty program now to unify that across the board. I won’t spend too much
time on the last part, because that’s the big meat
of how we got into VIP. The key thing to
talk about, though, from this solution that they
had, even once we brought it in-house from the
original program, was there was no dedicated
team to support it. If they needed data in, they’d
call somebody, whoever they knew in our integrations team. If they needed
something modeled, they’d have to go
with our BI team to change the internal
data model for them. So they just kind
of got in queue. They had no priority,
no emphasis on things, so they would get creative. They would start doing
their own work arounds, doing things, and
coming to IT later and say, hey, you
have to do this, because we’ve already
told our customers we’re doing this, which
would obviously create a lot of stir and
prioritization changes on the IT side. We’d have data fixes that
were just done in a vacuum that we then lived
through as we’re trying to implement and move
from an on-prem database to a cloud database. All those fixes had to
become reality and new life in our world. What are the asks and needs
for the new loyalty program? While this is DSW’s
program, we honestly view this as our customer’s
program, so we went out, and we surveyed. We asked the customers
what are they looking for. What do you want to do? What does DSW mean to you,
and what are you looking for in our loyalty program? There was some key
things that came out of that that really rope
up into these four points. Real-time everything– we
lived in a batch-based world where transactions came in
on a nightly sales screen. They were processed through,
and we would notify, hey, maybe you earned a reward
or maybe you earned a new tier, but you don’t get that reward
until seven days later. We’ve already lost
that engagement. We’ve lost that opportunity to
reconnect with that customer. We want to make sure we
can give them their points, give them their
tiers, communicate, not just via email. We wanted to implement
and get more into SMS and app push
notifications, make sure that customer recognizes that
you’ve transacted with us, re-engage with us,
move this forward, keep DSW in the front of their mind. Flexibility– the
customers wanted more ways to interact with us. We were a points-based
based on sales transactions. We wanted to be able
to give us your data, give us the interaction,
give this point in a store, donate shoes, other
things they wanted to do outside of just a
sales-based interactive program. From a marketing standpoint,
they wanted the flexibility to be able to move quickly. In their old world, they would
take up to two to three weeks to set up a new promotion,
and it was XML based. You had to wait on
batches overnight, where now we can react
in two to three hours. We can have a new promotion
set up and moving for them. A simplified program–
before points were 10 points for $1.00, or 20, or 25, or
30, based on where you were at, what promotions run,
so people would walk out of the store not knowing did
I even get the right amount of points, what happened,
call the call center, extra touch points, and
just confusion to what they ultimately were trying to do. Then, ultimately, as we
looked at all those points, we needed more data to
know about our customers. We want to make it more
personalized, more engaging, and more opportunities to make
that experience their very own. That came in on the back
end along with IT’s need to align to marketing’s needs. As I mentioned previously, there
wasn’t a team to support that. Cam and I help make
up that team now, we’ll get into a
little bit more later, but we recognize that as a need. If we’re really going
to jump into this and deliver what the
business really needs, we need to then,
in turn, give them a team that they can come
to, and actually drive them in line with their visions. With that, I’ll
turn it over to Cam, and he’ll talk us
through our new loyalty and how we got there. CAM HEIGHTLAND: Cool. My name is Cam Heightland. I’m the tech lead for the
marketing applications team. A little bit about myself– I’m from Columbus, Ohio. Engaged, getting
married in June. I’m having a huge
wedding that you can tell I’m really excited about. And then pretty much my kid– it’s my dog Romeo. He’s either really happy
or just really sassy all the time, which is pretty
much me throughout the project. I was really engaged, really
happy at the beginning, and then halfway through, I’m
probably snapping at everybody, and then at the end,
I’m really happy again. The big thing here
is I do understand that I have two
pictures of my dog and one picture of my fiancee. That was just to put
the point of the project was a little tough. If I did the same with
pictures of my fiancee, it probably wouldn’t work out
very well when I got home. Let’s get into
this a little bit. From a history
perspective, we had two databases that sat on prem. We had one analytics database. We had one real-time database. For the real-time database,
we had SOAP-based interactions that become pretty inflexible
as you’re moving forward, and we were just continually
building on tech debt, essentially, so every team
had their own operations. We were stuck with 90
operations that pretty much do the same thing over
and over again, which becomes a challenge,
but these really did just get your
customer information, update your customer
information, get your points. Pretty simplistic
stuff that we knew we couldn’t use moving forward. The other piece to this
is just that operations is kind of a nightmare. If we want to integrate
with third parties, that’s going to be a couple
months, because we have to do– from a security perspective,
we’re just mostly going off of firewall rules,
things like that, that take two to three
months with our existing infrastructure, so not what
we wanted to build upon. The second piece of
this is that we just had XML files going
down every week that changed to about every day, to
do points, give rewards, give tiers. We’ve kind of lost the customer
engagement at that point. Also, a lot of operations,
just a lot of pinprick things, that we have to deal with
that we just didn’t want to deal with moving forward. The last piece of this is we
had an analytics database. People would just run
huge queries trying to do models that would
tear it down, break it in the middle of
the night, people have to wake up just to
challenge– we have to scale. We had to move forward to that,
so we’re starting to do that. We had three options here. One option is we could
just keep building it on prem with the
things we wanted to do. That clearly wasn’t
what we could do. We could buy it off the shelf,
but then at some point– other customers are using this,
other companies are using this, so we’re not really
different than them. So we decided to
move to the cloud. We decided to
partner with Slalom. They were huge in
helping us really change our mindset
in architecture and helping us build
this moving forward. The challenge ahead of us
was that we didn’t have a lot of cloud experience– very in our infancy. We had a couple of
applications out there, but nothing huge like
loyalty was going to be. But also, like
Rich talked about, there was no central person
or team that owned this. It was all tribal knowledge. I’d be going meeting
to meeting finding out something different,
but at some point, we landed on a couple
of things, and we just had to move forward and go. We did that, but then we
got to our requirements, like the worst requirement
you can ever deal with, which is all current features
and functionality must be implemented in
the new system. That’s just kind of
like you open up a box, and everything’s
shaken up, and you have no idea what’s going on. But we were pretty eager. I’m a millennial, so I
just jump in and think I’m going to live forever. We just jumped into
it, got excited, but we wanted to
build a community, not necessarily just
a loyalty platform. We wanted to build a community. This is what we
wanted to build it on. We wanted to be API first. We wanted to enable
anything that’s in loyalty to be outside
facing that we can interact with our customers, not
just our regular customers, but also third parties,
anyone who wants to connect to our platform. The second piece to this
is being developer-centric, so no manual deploys. You don’t have to wake up
in the middle of the night to deal with things. We’re going to reheal
ourselves, and also, we’re just going to enable a
lot of automation and even third-party integrations. The biggest piece of moving
to the cloud, like everyone will talk about, just the
flexibility, scalability, and stability, and
that’s the biggest thing was just application
analytics for us. We can’t have our
real-time databases or real-time applications
getting impacted by models. So we’ve got to break
that apart and figure out how we’re going to scale. Then the last thing,
just real-time analytics. The big thing that
we dealt with is that we wanted to stream data
all the time in the old system, but we have an on-premise server
that has a bunch of licenses. We don’t want to
buy more licenses, so we’re only going to take
the data that we can take, and that’s going to hinder
our analytics as we’re moving forward, because
we’re not getting everything. We’re just getting pieces of it. How should we build loyalty? That’s the biggest piece. We need to build a platform
first and keep moving forward. We need to modernize
that as well. So what we did is we jumped in
Kubernetes just like everyone is talking about. We used Spring
Boot Java services, whether that was synchronous
or asynchronous communication, so API or event driven. We’re going to do that
to essentially enable our platform so it can scale to
the traffic and the customers that we’re going to have. We ended up creating seven
to nine microservices. If you want to talk
about technical details– I’m going to stay
pretty high level here, so we can talk after
or hit up the Dory– but we needed to make sure that
we could scale moving forward. We have a pretty small team,
especially starting off, and so dealing with a bunch
of operations, that’s just not going to work for us. So seven to 10 microservices. A couple that really
handle most of our APIs, just because of how large
it’s working right now, but then the rest were
really event-driven and could scale up,
scale down pretty easily. The biggest thing you will
hear every retailer talk about is you have a bunch of servers
for two months of the year, because that’s when all the
customers are coming to you. That’s when everyone’s
coming to you saying, hey, we need this right now. We need to shop. We need to buy
everything last minute. That’s kind of what
happens, but you’ve got servers sitting there
for the rest of the year, and they have licenses. You’ve got to pay for all that,
keep the lights on for it, so we want to make sure
we’re using what we can use and using it when we
need it, when customers are coming to us, when third
parties are coming to us, things like that. We got our loyalty platform. It could scale. It can interact pretty easily,
but how do we secure our APIs? Everyone talks about security. You need to have
it, but we needed to enable that pretty easily. We moved to Apigee, and
I’ve used Apigee previously, so this was a pretty
simple decision. Using this as our
gateway enabled a lot of the easy
security features for us. Also enabled a lot of
third-party integration, so being able to spin up a
developer portal pretty easily, putting YAMLs out
there, allowing people to just see it, interact
with it, ask for an API key, ask for auth. Easy to interact with, good
for us as we’re moving forward and we’re building this
developer community. And the biggest
piece that we really didn’t know about that really
helped us moving forward was the payload transformation. I’ll talk about this
a little later when it talks about
implementation, but we have a decent amount
of legacy systems, and we couldn’t change
those legacy systems, so that was a huge pain
as we got into things. But we got around
it, made things work, and Apigee was huge in that. How are we going to
enable analytics? Honestly, really
simple decision. I’ll show you our
pattern after this. Moved to BigQuery. We can easily scale everything. There’s hardly any operations. Data storage is cheap. We’re able to query petabytes
of data in 30 seconds– if we optimize it,
maybe 15 seconds– as we’re moving forward
and create whatever models we want to for our
analytics team. It’s a pretty easy decision. I blank out on it because it
was just the easy decision that we made. How do we get information
into the system and out of the system? This was the last piece. We’ve got our APIs
and API enablement. We’ve got our loyalty platform. We have our data warehouse. So cool, we’ve got everything,
but how do we stream? How do we get data in? This is pretty common for us. Again, Slalom’s huge with this. Pretty simple process. Drop a file into a
bucket, Cloud Functions, and kick off a
Dataflow job, and then spin up a serverless
architecture, boom, right to Cloud
SQL, right to BigQuery. Pretty simple decisions. We continue to do this as we are
also interacting with our APIs, so streaming-based
jobs enable us to really– anything we add
to our Cloud SQL database or any new API we
add, we can just update our objects comment. It’ll pick it up as
we redeploy the job, and boom, we can
stream everything to any of our tables. The last piece was how
do we enable developers. We could have
easily built loyalty and just said, here’s
loyalty, but we’re going to hurt ourselves
moving forward. We need to enable developers,
because there were so many times that we were
waiting on resources for two to three weeks. And it’s not
anyone’s fault, it’s just you’ve got to get servers,
or you’ve got to get licenses, or you’ve got to get whatever. The biggest thing with
going to the cloud is that you can
get rid of all that and not have to
deal with any of it. The biggest piece we used
is infrastructure as code, which would be Terraform. Terraform allowed us to
just do pull requests and have uniform environments,
uniform naming standards, everyone can see
everything, but we can build out whatever we
need at the time at which we need it. As we’re moving forward,
we can get new Pub/Subs, we can get a new
database, we can get whatever we
need in a fraction of an hour versus a week. Great for us. The last piece was
just the CI/CD. We’re still working
on this a little bit, but this was a pretty simple one
of just using Bitbucket storing all our code, and every time
something goes to Bitbucket, Jenkins kicks off,
pushes a build out there. We’re good to go. Readiness checks
blue-green, so we don’t have to deal with anything
in the middle of the day, and we can deploy
at any point in time and not have to worry about
doing this overnight and pretty simple, pretty easy
stuff to do with Jenkins. This is where it gets tricky. We had everything that
we wanted to have. We were really excited about it. And then a couple
months down the road, we’ve reloaded the
database about 30 times, changed the schema
about 60 times, and we’re all pretty
frustrated and just have to deal with how
implementation goes. Learning the new cloud
platform, there’s a little bit of a challenge. There’s a little bit
of mindset change, but the biggest thing is moving
all your existing challenges and problems and getting rid of
those and moving to the cloud. You can easily, if you
want to spin up a machine, put your stuff on a
machine, that’s pretty easy. We didn’t want to do that. We wanted to set ourselves
up for the future and keep moving there, so
we get an implementation. We’re going into every
meeting, and that requirement of everything existing
has to stay the same just kills us every single time. We’re coming in,
have a new feature about every other meeting, and
we’re probably six months down the road at this point. We’re dealing with all
these end requirements, so whether it’s tech debt
with logic built in APIs, logic built in stored procedures
that those APIs are calling, just the network latency. And it’s not the
cloud’s latency. It was our latency
that we didn’t want to admit to at times,
but that was a big challenge. And the other challenge is that
we just weren’t really set up. You’re never going to be ready
when you’re moving straight to the cloud. You’ve just kind
of got to do it. You’re going to
have the challenges. There’s going to be pain
points, but just do it. It’s going to be worth
it in the future, but you’re going to
have to deal with it. The last one is integrating
with legacy applications, whether it was
[INAUDIBLE] XML, people are looking for
these certain fields. There’s a bunch of
transformations in the APIs that aren’t real
in the database. We dealt with it all. We dealt with those problems,
and really, the biggest problem was just day-to-day data. We didn’t necessarily
know what our data was, and that’s just because
of the tech debt we’d built up over years. We get through it all. We’re starting to
get some steam, and we get about
three weeks out. And we’re like,
man, we just totally forgot about this piece. We didn’t have any
dashboards set up. We weren’t sure what we needed
from an alert standpoint, but luckily– this is my one pitch to Google– Stackdriver was awesome. It easily integrates
with everything else you’re going to do,
whether it’s latency, APIs with Google
endpoints, alerts, dashboards– you
name it, it’s got it. It was awesome for us,
really easy to set up, and we could just have
everything overnight, and we still use it today. Pretty awesome. Also, just with error reporting,
huge for us for bug visibility. We could figure out
who made this call at this time, what operation
died at that point, and what was the issue. We get to the last
three weeks, and I know I did some 7:00
AM to 2:00 AM shifts, so it was kind of
tough at that point. But luckily, everything
actually went pretty flawlessly. We had a bunch– a couple, not a
bunch– but we had a couple of scares going
into the night we go live. Probably the best story
is the one day we actually were about to go live,
and we had to call it off because our points
were messed up. And then Kevin and team brought
us a cake that day for go live. That felt great. But that was one of
the funny stories. I think a couple days later,
we actually did go live. RICHARD CLUM: Yeah. CAM HEIGHTLAND: You can look
back and laugh at it now. But yeah, it was tough. It was tough during
the point in time. But yeah, we went live. And honestly, we were so
close to Black Friday, it was a little bit
of a concern for sure. But honestly, we
had a lot of peace of mind moving to the cloud. With everything we
had had, we were killing all of our
performance numbers without actually
optimizing everything. So we hit a ton of
numbers that we wouldn’t have hit in previous programs. Things that would go
down during peak times were easily scaling up. And we had no problems at all. Black Friday time, we
were hitting numbers. We hit numbers that we’ve
never hit before, which were huge for us and awesome. But what I’ll say is that
with going to the cloud, Google’s been great
partners, awesome partners, but moving to the
cloud itself, it’s just peace of mind
at some point, for us, with a team
that’s pretty small and have to do deal
with the operations, have to do with everything. I had come from
on-prem world where I’d be up in the
middle of the night. I don’t have to worry
anymore at this point. I know things are
going to scale up. I know things are going
to reheal themselves. And everything’s a lot easier
as we’ve been moving forward. Especially even
building new features, everything’s a lot easier
because I don’t have to worry about my resources. I don’t have to worry about
what I need to develop the tools and move our program forward. So here’s what we did. This is what we started with. We weren’t 100% sure. We’re like, this is
really a lot of the tools that we thought we needed. But we didn’t need these
tools to move forward, and this is what we ended with. The biggest piece of
this is we’re continuing to add new features every day. [INAUDIBLE] Data
Fusion, Cloud Run, which looks awesome for us. But things are
getting a lot easier. And we’re able to get
these really quickly. If we would have went with a
third party, essentially just someone we bought off the shelf,
or if we would have bought it on prem, there’s no way we would
have made it at a year’s time to actually deploy this thing. There were so many
changes that we had to do not because
of bad architecture, but it was what we
knew at the time. We were able to change
easily throughout time and continually change as we’re
moving forward on the platform. So I’m going to give
this to Rich now. If you have any questions,
feel free to catch me after. Feel free to ask the Dory. And thank you. RICHARD CLUM: Thanks, Cam. So yeah, I want to talk you
through where we’re at today. Obviously, enabling
this platform for all of our
marketing partners, our analytics partners to
really drive this forward. So there’s some
quick stats on where we’re at since we’ve launched. Again, this was September
25th, a day that will forever be stuck in my mind. Some quick numbers we’ve done. One that we’re very
proud of is that top one up there in the corner, rated
number one most innovative loyalty program by Shopify. Something obviously we pat
ourselves on the back about. But realized now that
we’ve launched this and we’re out there, we
have to keep that going. We’ve reached the
top very quickly. We appreciate that. A lot of things went into that. And now, obviously,
we want to stay there. Cam mentioned this. We went close to holiday. So think about it, that’s two
months prior to Black Friday. This past Black Friday, we
hit some of the highest sales, the highest sales numbers
on an hourly basis that DSW has ever seen. And that number
speaks for itself. Absolutely zero issues
on our platform. We were going through holiday
readiness plans and like, who’s going to be on site? Who’s going to do this? And we’re like, we’re going
to go ahead and support this from remote. We’ll sleep in. If you call us, need us. Zero phone calls. The other thing is we
moved into the cloud. And again, we went
from an environment that didn’t move very quickly. We’ve done, since go live, over
900 enhancements and bug fixes to our platform. That kind of goes with a big
pat on the back for our friends at Slalom, helping us move
to that agile platform, as well as what the
cloud has given us from a deliverability standpoint
to continuously improve and move upon what’s out there. Another big one
was, again, trying to stay in contact
with our customers to do mobile pushes from
the app notifications. Based on previous
system limitations, we had to break our audience
into eight different groups and slowly send it out. Make sure it sent. Make sure we didn’t
kill the network. Through performance testing
as we led up to the holidays, we got that down to one
big group of people. And it’s like, all right,
we’re going to send it. And we brought up Stackdriver,
monitoring the logs. OK, there was the
blip, and we’re done. And it wasn’t even, like you had
to zoom in and find the blip. Like did it really hit? Did you guys actually do this? We fine? 100% fine. Ongoing opportunities, so
obviously, we’re out there. We’re live, moving through it. As Cam mentioned, I mentioned,
we have a very small team. So it’s the continuous
growth of our engineers. We have a couple on
our team individually. We have a strong
contractor base. And again, partnered with
Slalom has been ongoing. But we just need to
continue growing them. We’re new to the cloud. We understand it. But this platform and our
partnership with Google has allowed us to continuously
grow and understand that the sky’s the limit from
where we want to go internally as a team. Cam hit on this as
well, our DevOps. So we had DevOps as
a DSW organization for the on-prem
platforms that we had. But now we’re
talking cloud DevOps. That means something
different to them. When they’re asking,
OK, how are your backups going to be handled? When are your patching
going to handle? What are you scheduled for that? We’re like, I don’t know. Let’s call Google. Let’s find out. We didn’t have to
worry about that. We had our guys focused
on what was important and that was delivering those
900-plus fixes ongoing day after day. By the way, if you
do the math, that’s like five per day,
business days, that we’ve deployed since then. So pretty staggering numbers. But it’s getting
that DevOps side up to speed because we know
we’re going to continue to develop on and on and on. And we need to make sure
that back end is handled, incidents are
properly addressed, data things are there,
so I can keep the people like Cam developing the
front end things that are important to us. And alongside of that
is just the education. So obviously, we’ve been
living and breathing Google Cloud for
over a year now, working very close with Kevin
and team, getting out there. But groups like our audit team,
our security team, our database admins, how can we perform this? And what can we do for them? Again, we don’t
need you to do that. But here’s how you help us. Here’s how you can
help us move forward to keep DSW moving in
the right direction. Team challenges. So we’re very proud. We’ve built this
j time application that performs at scale that does
everything we need it to do. But we still live in
a batch-based world. So every night, we still have
to take snapshots, get it down to our on-prem database. We still have to get that
data down to third parties. We’re still working through
those legacy systems and legacy applications to make
sure they’re whole. But it makes it
difficult. And they’re like, OK, we sent the data
down to EDW last night. Can you run a query
to validate that? Yes, I can. I can go to BigQuery. I can use all my data dates. But our application
is built to know, what are you doing in the moment
for that real-time snapshot? Project tech debt. So timeline compromises,
things led to, we just can’t get this done
in the timeline we need to. There were some analytics
things they needed or some data things they needed. We’re like, we’ll get to that. But we had a deadline
we needed to meet. But via the agile
process using JIRA, using the process
we have, we know we can just recover from that. And we’re not going to build
ourself a 12-year period tech debt that we absorbed as
we took on this project. And that kind of leads
into the last one. So our backlog is out there. We know what it is we
have to work through. But now we’ve enabled a process
for our marketing partners to realize that they can
get stuff as quickly as they can almost ask for it. So we went live in September. Just here in the
next couple weeks, we have another pretty
big release coming out. We already have another one
scheduled for the fall as well. So as I’m looking through
that trying to make sure that we are making
sure that we prioritize to dig through our backlog,
make sure our tech debt doesn’t get up there, as well
as we’re making sure that we can support
the business for their ongoing opportunities. As I mentioned to
start with, we really didn’t have a marketing
team or an IT team to support our
marketing partners. So as this came along,
again, my team was stood up, and I brought on people
like Cam and other folks to give our DSW marketing
partners not just one team to deal with, the Designer
Brands Marketing IT team, but obviously, we have a great
partnership with Google Cloud. And our partners
at Slalom as well help us really build from what
was a very disjointed process to a collaborative group that
continue moving us forward. Slalom came in, again, day
one of our project, really helped us build out
that architecture that Cam walked you through. But it wasn’t a go
live’s done, we’re out. They’re still there. They’re still helping
us build our strategy, making sure that as we’re
looking for what we have done and what we’re doing
forward, we’re not putting ourself into a hole. And they’ve been a
great partnership. It’s been, even though
they’re based out of Atlanta, we’re based out of
Columbus, we didn’t even see that as a problem. The interaction and
communication, we never caught them off guard. And they never
caught us off guard. And then growth, so as Kevin
mentioned to start with, when we launched this and
started going into it, we were DSW Inc.
Since then, we just recently rebranded ourself. And as a parent company,
we’re Designer Brands Inc. What that really means is we
as a IT shared services support all these brands now. So DSW VIP is live for the US. We have DSW Canada. So we’re in the process of
moving them over to the cloud and using our same
loyalty platform for our Canadian-based stores. Shoe Co. and Shoe Warehouse have
a loyalty program also based in Canada that we’re
in the process, again, rewriting that, moving
it to the cloud. They quickly saw the benefits
that we had and implemented for our US-based stores and
asked not, can we have it? It’s, can I get it tomorrow? They understand
what kind of value we’re driving to keep
their program moving. We also have the Camuto Group
and our affiliated business groups that typically they come
in, OK, hey, can you do this? Can you guys handle this? Cam and I are sitting
there going, essentially, bring it on. Give me more people
to help do it because we need it to happen. But the cloud has given us
a platform that we don’t have to say no to anymore. Analytics team, we
can enable them. The data is there. They’re not asking us
to remodel anything. Here’s BigQuery. You go after it. If you need more stuff,
we’ll get it to you. But we can get it to you quick. And Cam kind of hit
on this as well, and this is kind of
our thing that we have realized as we’ve gone
through the whole process is there was no shortcuts
of getting to the cloud. We wanted to make
sure we did it right. But since we’ve gone live,
we’ve recognized fully that it’s 100% worth it. No looking back. No questions, did we
do the right thing? Did we not do the right thing? It’s been since
literally the first time we started streaming
data into it, and we’re like, OK,
that data was bad. We have to redo it. It was quick to fix it. Quick to move forward
and just recognize the benefits of the data
stores, the opportunities, the data flows that we’ve used. Our friends at Slalom can
vest for how many times we asked them to pivot and change. But the cloud gave
us that capabilities. The infrastructure scales. Everything there helped us out. And again, that growth slide
that we just talked to, limits of where
we’re going and what we’re going to do for
Designer Brands as a whole. [MUSIC PLAYING]

Leave a Reply

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