[MUSIC PLAYING]
BRUNO AZIZA: Welcome to another episode of data Journeys.
This is the place we come to learn from data leaders who
have experienced amazing growth and have lots of learnings
to share with us today.
I'm excited to talk to Pedro from FARFETCH.
FARFETCH is a company that went public just a few years ago,
2 million active users on their platform, $3 billion
in revenue, 49% year over year growth.
They have 30 data teams.
That's 300 people that are working on data.
So certainly we have a lot to learn from Pedro.
Pedro, thank you so much for taking the time
to talk to us today.
Let's get started.
And tell us about FARFETCH.
What is the company?
PEDRO TROIA: So, FARFETCH is a company
that aims to be the global platform for the luxury
industry.
We are more than 5,000 people all around the globe.
And we are most known by our marketplace, FARFETCH.com,
where we sell products, luxury products, from our partners.
So over this last year, since we launched the marketplace,
we have been also looking at other business areas.
We created the White label solution
area for e-commerce, which is FARFETCH Platform Solutions.
We acquired some companies like Browns,
Stadium Goods, New Cards Group.
And we partnership with some of the big players
that we have within the luxury industry world.
BRUNO AZIZA: And so you have amazing growth.
You started in 2008, went public in 2018.
So you've had an amazing growth throughout these years
and, of course, a lot of data.
So tell us a little bit about the volume of your data
and the type of use cases that you're using this data for.
PEDRO TROIA: Yeah, that's right.
Well, we use a lot of data.
So to have an idea on the numbers,
we have around five petabytes of data.
We have more than 1,000 sources that we use daily.
We have more than 700 data users.
For example, in BigQuery, we have more than 500 active users
every single day.
This is really, really interesting.
And to give you an idea, we have 6 million queries
every single month, which, as I understand, it's quite a lot.
BRUNO AZIZA: Yeah it's really quite impressive.
And you're using multiple parts of the stack using, of course,
BigQuery.
But you're also using Data Prop for your data
lake, Data Studio, Composer.
And you've done this for over three years.
Tell us a little bit about the use cases
that you've developed, in particular,
the omni-tracking use case.
PEDRO TROIA: And that's a really interesting one,
as you were saying.
We implemented this tech for almost four years now,
at three and a half years.
And we use all this technology that you mentioned.
So we decided to move to GCP and to all these other Google tech
pieces because we were struggling with the legacy tech
stack that we used.
So we started to move and to use BigQuery and GCP,
not only as our query engine, but also as the corporate data
warehouse, let's call it that way.
Some people may discuss about if it is or not a data warehouse.
But, well, let's call it that way for now.
One of the most recent examples that we have is omni-tracking.
So as you can imagine, we are a really big marketplace.
We have more than 2 million active customers.
So we need data.
But we gather a lot of data, too.
So we have all these tracking solutions.
And, two years ago, we decided to create our own tracking
solution to capture data both from the web
and from our mobile apps.
So, it was a big project, as you can imagine.
And we delivered it recently.
And we are now using all these features and the product
as the basis for all the analysis
that we do with that data afterwards.
BRUNO AZIZA: Can you tell me more
about this omni-tracking project?
I mean, 2 million users, the data, I'm sure,
is used across multiple business units inside your organization,
marketing, and finance.
What specifically are you analyzing with this data?
Is this for offers?
Is this for understanding the journey of these visitors?
How is the data kind of being used?
PEDRO TROIA: For now, we are really focused on product.
And we are looking to the customer journey, too.
So, it's trying to understand not only how the customers use
our websites, our apps, but how can we
use that data to create a different customer
experience to them.
So, that's one of the focus.
We started to work a lot with one of our departments
because they knew a lot about tracking.
And it's really interesting that suddenly we
have several other departments that want
to use also this new product.
So they came to us with their requests and with the features
that they would like to use or even within your requirements.
And from the point that we deliver the project,
we are already thinking of enriching the product itself
because it seems to be a good source of data
to several areas within the company.
BRUNO AZIZA: This might lead to our best practice section
here of this interview.
But I'm curious about who were the first folks in the business
department?
Did you start with marketing?
Did you start with finance?
Where did you start?
PEDRO TROIA: In this specific case,
we started to work with our product analytics team
and with marketing.
So these were the two areas that we started with.
BRUNO AZIZA: And what is the next department
you're going after then now?
PEDRO TROIA: We are now looking actually
to use the solution across all the company.
Because as I mentioned, there are really, really a lot
of areas that want to use it.
So, we are talking now about finance, about commercial.
For example, I would say that those would be the next areas
to use these products.
BRUNO AZIZA: So through this migration you've learned a lot
and you've accumulated technical best practices.
What are kind of the two or three things
that people need to think about as they're
embarking on similar journeys?
PEDRO TROIA: The first one is you should have teams 100%
focused and with a clear mission for them to achieve.
So I believe that's really, really important.
Of course, this depends on the dimension of the project
that you are talking about.
But it's more than proved that if you have teams focused,
the results are quite better.
We can also talk about creating mechanisms
that help to unblock any situation that arises.
And we don't want the teams to stop working right,
to stop their development, and to stop publishing
their products that we have.
So, think about it and create all these mechanisms.
And I believe that's really, really helpful.
It's also really important to think
on the approach for each of these projects
that you have concerning how will you organize the teams.
So, I would say for a big project,
maybe it makes sense coming back to the first point
that you have, teams fully dedicated
in their specific area of knowledge.
So maybe you have people focused on ETL.
Then you have people focus on the BI part,
and so on, and so on, and so on.
In other projects, smaller ones, for example,
maybe you can have one that is full stack
and they can work it from the beginning
till the delivery of the project.
And I would say anticipate failure.
And by that, I mean, we know that things fail.
The ETL may break.
Data quality can be bad.
Things just go wrong.
You can have a problem in your infrastructure, for example.
We know these, at some point in time, will happen.
So think ahead.
And think how you can anticipate potential problems.
Because in some cases, you can do it.
And I'm not just talking about creating these mechanisms
around data quality, for example.
It's around creating some kinds of alerts, comparing data.
And this is interesting because here it
is use data to anticipate problems that you can
have with your data platforms.
I think that's really something that we must assume.
We'll have some problems, let's think
how we can anticipate them in order
to avoid mitigation measures that we'll implement
after the problems rise.
BRUNO AZIZA: So use data on data.
PEDRO TROIA: Yeah.
People forget to do it.
BRUNO AZIZA: Anticipate ETL jobs--
Yeah, anticipate that ETL jobs will fail.
Anticipate that data quality is going to be bad
and any other issues like that.
So you start that at the beginning
of the project so you can build your alerts just the way
you did it.
OK, those are great best practices.
Now, let's talk about the opposite, the things
that you wish you had known when you started.
We call them the worst practices.
If you talk to yourself at the beginning of this project,
what would you tell yourself don't do this thing
because it's going to get you in trouble.
PEDRO TROIA: It's no different from other companies
that I've worked before, to be honest.
But one thing that is important is using, again, only
tracking as an example, we are talking
about the product that is to be used for the entire company.
So, you can start with requirements
from a specific area, but you should
consider that when developing or thinking about the solution,
that other areas will use it.
So the solution should already consider this.
So, even that you don't go to the details
of those requirements, you should
have an holistic approach and to think that this
will be used by everyone.
Something that is really, really hard to manage is timings.
So, most of the times we rush to a decision
because we want to have that product or the project ready as
soon as possible.
And a lot of times this leads to bad solutions.
So what I would say here is do the right thing
in a timely manner, but do it right.
So I believe that that's really, really important.
And then there are a lot of more technical things
that we should avoid, like cumulative metrics,
avoid joints, of course, and avoid runtime logic.
I know that most companies use these kinds of things,
as we do.
Because, again, you need to have answers
and you need to have them quickly.
So sometimes it's not about the best solution.
It's about having a solution in a quick way.
But I would say that these are the main examples that I
can give now.
BRUNO AZIZA: So those is a great example.
Think wide and assume everybody is
going to be using the solution ultimately,
so you can have a solution that can adapt.
In your case, starting with one department
and quickly going to the rest of the company.
I am curious about avoiding cumulative metrics.
Can you tell us more about what that is,
or what is the issue there?
PEDRO TROIA: The issue there is mainly around fast data.
So, when you change anything, if you
need to backfill the information using cumulative metrics,
this turns the whole process much, much harder.
So that's just one example.
There are others if you need to repossess something
or something like that.
But yeah, that's what it is about.
BRUNO AZIZA: And would you say using cumulative metrics is
something we used to do in the past
because we didn't have the options that we have today?
Or what's behind this guidance?
Because I think when people move to the cloud
and they modernize their stack, there
are concepts that existed in the past that were best
practice in the past that are no longer best practices here.
Is this one of those?
PEDRO TROIA: I think we can consider that.
And is exactly as you are saying.
We are in a completely different moment
than we were five, 10 years ago.
Unfortunately, we continue to use the same mindset.
In lots of--
I talk with a lot of colleagues, a lot of companies,
and they continue to work that way.
And nowadays we have so many solutions.
We have different burdens that we can use and look to.
It makes sense to think things in a different manner.
So, it's not, in most of the cases,
it's not about the technology.
So usually it's more around this solution,
the way that you design the solution,
and all the processes associated with it.
BRUNO AZIZA: We talked a lot about that
when we talk with customers and people
in the industry that have been there for a long time.
They'll expect things from a new platform that was there before.
But we actually don't--
we tend to forget the reasons for why these things were there
before, like things like index.
And you talked about joints here.
It's a great example, as well.
What about runtime logic.
Tell me more about what's going on there.
Why do you want people to avoid runtime logic?
Why do you think it's something to watch out for?
PEDRO TROIA: Usually, the thing here
is to avoid adding this logic in views or in the reporting
layer.
Why, because if you have this logic in the end of the,
let's call it data cycle, when it
is about to be consumed, if you want to change anything,
for example, in your data warehouse, in your [INAUDIBLE],,
in your data lake, whatever, most of the times
this will have impacts in the end of that lifecycle.
And, again, the life cycle I'm talking just before the data
is about to be consumed.
And what I also know that happens is that the people that
do this, by the end of this data journey,
they are not so skilled in tech.
So actually they struggle a bit to have these changes.
And that's another one.
Even if they have, for example, in FARFETCH actually
people have this knowledge.
But here a problem of communication
arises which is, in our case, for example,
we have more than 30 data teams across the organization.
And they have teams within.
So it's a lot of people, more than 350 people.
So, making sure that any change that we have that
can somehow create that breaking change in this data flow,
it's hard to get the message to everyone.
So the probability of one change,
even if it was communicated to create
a breaking change by the end of this chain, is quite high.
And so if you can anticipate all the logic,
it's like sometimes it's not possible.
But whenever possible, I believe that's the best way to do it,
even because you can, for example, in the reporting
tools and all of that, take that out,
and actually you'll gain lots of performance there, too.
BRUNO AZIZA: So, yeah, so it's a matter
of basically better performance for the people consuming.
Are using materialized views, or what are you using?
PEDRO TROIA: I would say the answer
to that is we use it all.
But, yes, we also use materialized views.
Yeah, it's really a big, big department.
So we use, well, everything.
BRUNO AZIZA: So let me ask it.
So, now that you've achieved such a level of maturity,
where are you going to next?
PEDRO TROIA: So, focusing on data, what I wanted to do
is to create a global reference data platform.
So I'm not saying the best platform in the world,
but one that people can refer to.
We want to enable and to foster the use of data
within the company.
And I want also to make sure that FARFETCH is recognized
not only in the luxury industry and within tech,
but also for data.
So that's something that I would really like to achieve.
And we have some challenges, of course.
FARFETCH is growing a lot year over year.
We must have a platform that is resilient that accommodates all
this growth and all the features that the growth implies
and all the changes in the industry imply, and in tech,
of course.
And we want to be able to quickly adapt
to anything new that rises, either
from an organic perspective or something
that happened outside.
And we must adapt for some reason.
And I would love to have a platform that
allows us to do that.
BRUNO AZIZA: Pedro, thank you so much for your time today.
That was just amazing.
We learned how you need to build teams
that are focused on particular parts of the process.
We learn how to build for failure from the beginning,
build alert so you can anticipate ETL jobs failing,
use data on data to check on data quality.
And, of course, don't be narrow in your approach.
Think about this idea that your product,
just like in your case, is going to be
used across many departments.
So think about the multiple user types and personas.
Thank you again so much for spending the time with us
today.
I hope people are going to reach out to you to learn from you.
In fact, if you want to learn more from companies just
like this one, click on the link down below.
Until next time, I'm Bruno Aziza.
[MUSIC PLAYING]