This article mainly draws on our published paper in KDD 2019 (Oral Presentation, Selection Rate 6%, 45 out of 700).
Nowadays an internet company typically has a wide range of online products to fulfill customer needs. It is common for users to interact with multiple online products on the same platform and at the same time. Consider, for example, Etsy’s marketplace. There are organic search, recommendation modules (recommendations), and promoted listings enabling users to find interesting items. Although each of them offers a unique opportunity for users to interact with a portion of the overall inventory, they are functionally similar and contest the limited time, attention, and monetary budgets of users.
To optimize users’ overall experiences, instead of understanding and improving these products separately, it is important to gain insights into the evidence of cannibalization: an improvement in one product induces users to decrease their engagement with other products. Cannibalization is very difficult to detect in the offline evaluation, while frequently shows up in online A/B tests.
Consider the following example, an A/B test for a recommendation module. A typical A/B test of a recommendation module commonly involves the change in the underlying machine learning algorithm, its user interface, or both. The recommendation change significantly increased users’ clicks on the recommendation while significantly decreasing users’ clicks on organic search results.
Table 1: A/B Test Results for Recommendation Module （Simulated Experiment Data to Imitate the Real A/B Test）
% Change = Effect/Mean of Control
Note: ‘***’ p<0.001, ‘**’ p<0.01, ‘*’ p<0.05, ‘.’ p<0.1. The two-tailed p-value is derived from the z-test for H0: the effect is zero, which is based on asymptotic normality.
There is an intuitive explanation to the drop in search clicks: users might not need to search as much as usual because they could find what they were looking for through recommendations. In other words, improved recommendations effectively diverted users’ attention away from search and thus cannibalized the user engagement in search.
Note that increased recommendation clicks did not translate into observed gains in key performance indicators: conversion and Gross Merchandise Sales (GMS). Conversion and GMS are typically measured at the sitewide level because the ultimate goal of the improvement of any product on our platform is to facilitate a better user experience about etsy.com. The launch decision of a new algorithm is usually based on the significant gain in conversion/GMS from A/B tests. The insignificant conversion/GMS gain and the significant lift in recommendation clicks challenge product owners when deciding to terminate the new algorithm. They wonder whether the cannibalization in search clicks could, in turn, cannibalize conversion/GMS gain from recommendation. In other words, it is plausible that the improved recommendations should have brought more significant increases of conversion/GMS than what the A/B test shows, and its positive impact is partially offset by the negative impact from the cannibalized user engagement in search. If there is cannibalization in conversion/GMS gain, then, instead of terminating it, it is advisable to launch the new recommendation algorithm and revise the search algorithm to work better with the new recommendation algorithm; otherwise, the development of recommendation algorithms would be hurt.
The challenge asks for separating the revenue loss (through search) from the original revenue gain (from the recommendation module change). Unfortunately, from the A/B tests, we can only observe the cannibalization in user engagement (the induced reduction in search clicks).
Flaws of Purchase-Funnel Based Attribution Metrics
Specific product revenue is commonly attributed based on purchase-funnel/user-journey. For example, the purchase-funnel of recommendations could be defined as a sequence of user actions: “click A in recommendations → purchase A”. To compute recommendation-attributed conversion rate, we have to segment all the converted users into two groups: those who follow the pattern of the purchase-funnel and those who do not. Only the first segment is used for counting the number of conversions.
However, the validity of the attribution is questionable. In many A/B tests of new recommendation algorithms, it is common for recommendation-attributed revenue change to be over +200% and search-attributed revenue change to be around -1%. It is difficult to see how the conversion lift is cannibalized and dropped from +200% to the observed +0.2%. These peculiar numbers remind us that attribution metrics based on purchase-funnel are unexplainable and unreliable for at least two reasons.
First, users usually take more complicated journeys than a heuristically-defined purchase-funnel can capture. Here are two examples:
If the recommendations make users stay longer on Etsy, and users click listings on other pages and modules to make purchases, then the recommendation-attributed metrics fail to capture the contribution of the recommendations to these conversions. The purchase-funnel is based on “click”, and there is no way to incorporate “dwell time” to the purchase-funnel.
Suppose the true user journey is “click A in recommendation → search A → click A in search results → click A in many other places → purchase A”. Shall the conversion be attributed to recommendation or search? Shall all the visited pages and modules share the credit of this conversion? Any answer would be too heuristic to be convincing.
Second, attribution metrics cannot measure any causal effects. The random assignment of users in an A/B test makes treatment and control buckets comparable and thus enables us to calculate the average treatment effect (ATE). The segments of users who follow the pattern of purchase-funnel may not be comparable between the two buckets, because the segmentation criterion (i.e., user journey) happens after random assignment and thus the segments of users are not randomized between the two buckets. In causal inference, factors that cause users to follow the pattern of purchase-funnel would be introduced by the segmentation and thus confound the causality between treatment and outcome. Any post-treatment segmentation could break the ignorability assumption of the causal identification and invalidate the causality in experiment analysis (see, e.g., Montgomery et al., 2018).
Causal Mediation Analysis
We exploit search clicks as a mediator in the causal path between recommendation improvement and conversion/GMS, and extend a formal framework of causal inference, causal mediation analysis (CMA), to separate the cannibalized effect from the original effect of the recommendation module change. CMA splits the observed conversion/GMS gains (average treatment effect, ATE) in A/B tests into the gains from the recommendation improvement (direct effect) and the losses due to cannibalized search clicks (indirect effect). In other words, the framework allows us to measure the impacts of recommendation improvement on conversion/GMS directly as well as indirectly through a mediator such as search (Figure 1). The significant drop in search clicks makes it a good candidate for the mediator. In practice, we can try different candidate mediators and use the analysis to confirm which one is the mediator.
Figure 1: Directed Acyclic Graph (DAG) Note: It illustrates the causal mediation in recommendation A/B test.
However, it is challenging to implement CMA of the literature directly in practice. An internet platform typically has tons of online products and all of them could be mediators on the causal path between the tested product and the final business outcomes. Figure 2 shows that multiple mediators (M1, M0, and M2) are on the causal path between treatment T and the final business outcome Y. In practice, it is very difficult to measure user engagement in all these mediators. Multiple unmeasured causally-dependent mediators in A/B tests break the sequential ignorability assumption in CMA and invalidates CMA (see Imai et al. (2010) for assumptions in CMA).
Figure 2: DAG of Multiple Mediators Note: M0 and M2 are upstream and downstream mediators of the mediator M1 respectively.
We define generalized average causal mediation effect (GACME) and generalized average direct effect (GADE) to analyze the second cannibalism. GADE captures the average causal effect of the treatment T that goes through all the channels that do not have M1. GACME captures the average causal effect of the treatment T that goes through all the channels that have M1. We proved that, under some assumptions, GADE and GACME are identifiable even though there are numerous unmeasured causally-dependent mediators. If there is no unmeasured mediator, then GADE and GACME collapse to ADE and ACME. If there is, then ADE and ACME cannot be identified while GADE and GACME can.
Table 2 shows the sample results. The recommendation improvement led to a 0.5% conversion lift, but the cannibalized search clicks resulted in a 0.3% conversion loss, and the observed revenue did not change significantly. When the outcome is GMS, we can see the loss through cannibalized search clicks as well. The results justify the cannibalization in conversion lift, and serve as evidence to support the launch of the new recommendation module.
Table 2: Causal Mediation Analysis on Simulated Experiment Data
% Change = Effect/Mean of Control
Cannibalization in Gain
The Original Gain from recommendation
GADE(0) (Direct Component)
The Loss Through Search
GACME(1) (Indirect Component)
The Observed Gain
ATE (Total Effect)
Note: ‘***’ p<0.001, ‘**’ p<0.01, ‘*’ p<0.05, ‘.’ p<0.1. The two-tailed p-value is derived from the z-test for H0: the effect is zero, which is based on asymptotic normality.
The implementation follows a causal mediation-based methodology we recently developed and published on KDD 2019. We also made a fun video describing the intuition behind the methodology. It is easy to implement and only requires solving two linear regression equations simultaneously (Section 4.4 of the paper). We simply need the treatment assignment indicator, search clicks, and the observed revenue for each experimental unit. Interested readers can refer to our paper for more details and our GitHub repo for the analysis code.
We have successfully deployed our model to identify products that are prone to cannibalization. In particular, it has helped product and engineering teams understand the tradeoffs between search and recommendations, and focus on the right opportunities. The direct effect on revenue is a more informative key performance indicator than the observed average treatment effect to measure the true contribution of a product change to the marketplace and to guide the decision on the launch of new product features.
We’re proud to say that our Webpack-powered build system, responsible for over 13,200 assets and their source maps, finishes in four minutes on average. This fast build time is the result of countless hours of optimizing. What follows is our journey to achieving such speed, and what we’ve discovered along the way.
At Etsy, our frontend consists of over 12,000 modules that eventually get bundled into over 1,200 static assets. Each asset needs to be localized and minified, both of which are time-consuming tasks. Furthermore, our production asset builds were limited to using 32 CPU cores and 64GB of RAM. Etsy had not yet moved to the cloud when we started migrating to Webpack, and these specs were of the beefiest on-premise hosts available. This meant we couldn’t just add more CPU/RAM to achieve faster builds.
So, to recap:
Our frontend consists of over 1,200 assets made up of over 12,000 modules.
Each asset needs to be localized and minified as part of productionization.
We are limited to 32 CPU cores and 64GB of RAM.
Production asset builds need to finish in less than five minutes on average.
We got this.
General caching solutions help reduce build times, idempotent of localization’s multiplicative factor. After we solved the essential problems of resolving our module dependencies and loading our custom code with Webpack, we incorporated community solutions like cache-loader and babel-loader’s caching options. These solutions cache intermediary artifacts of the build process, which can be time-consuming to calculate. As a result, asset builds after the initial one finish much faster. Still though, we needed more than caching to build localized assets quickly.
One of the first search results for Webpack localization was the now-deprecated i18n-webpack-plugin. It expects a separate Webpack configuration for each locale, leading to a separate production asset build per locale. Even though Webpack supports multiple configurations via its MultiCompiler mode, the documentation crucially points out that “each configuration is only processed after the previous one has finished processing.” At this stage in our process, we measured that a single production asset build without minification was taking ~3.75 minutes with no change to modules and a hot cache (a no-op build). It would take us ~3.75 × 11 = ~41.25 minutes to process all localized configurations for a no-op build.
We also ruled out using this plugin with a common solution like parallel-webpack to process configurations in parallel. Each parallel production asset build requires additional CPU and RAM, and the sum far exceeded the 32 CPU cores and 64GB of RAM available. Even when we limited the parallelism to stay under our resource limits, we were met with overall build times of ~15 minutes for a no-op build. It was clear we need to approach localization differently.
For a different locale, the message catalog contains analogous localization strings for the locale. We programmatically handle generating analogous message catalogs with a custom Webpack loader that applies whenever Webpack encounters an import for localizations. If we wanted to build Spanish assets, for example, the loader would look something like this:
Second, once we build the localized code and output localized assets, the only differing lines between copies of the same asset from different locales are the lines with localization strings; the rest are identical. When we build the above example with English and Spanish localizations, the diff of the resulting assets confirms this:
Even when caching intermediary artifacts, our Webpack configuration would spend over 50% of the overall build time constructing the bundled code of an asset. If we provided separate Webpack configurations for each locale, we would repeat this expensive asset construction process eleven times.
We could never finish this amount of work within our build-time constraints, and as we saw before, the resulting localized variants of each asset would be identical except for the few lines with localizations. What if, rather than locking ourselves into loading a specific locale’s localization and repeating an asset build for each locale, we returned a placeholder where the localizations should go?
We call this approach “localization inlining”, and it was actually how Builda localized its assets too. Although our production asset builds write these sentinel assets to disk, we do not serve them to users. They are only used to derive the localized assets.
With localization inlining, we were able to generate all of our localized assets from one production asset build. This allowed us to stay within our resource limits; most of Webpack’s CPU and RAM usage is tied to calculating and generating assets from the modules it has loaded. Adding additional files to be written to disk does not increase resource utilization as much as running an additional production asset build does.
Now that a single production asset build was responsible for over 13,200 assets, though, we noticed that simply writing this many assets to disk substantially increased build times. It turns out, Webpack only uses a single thread to write a build’s assets to disk. To address this bottleneck, we included logic to write a new localized asset only if the localizations or the sentinel asset have changed — if neither have changed, then the localized asset hasn’t changed either. This optimization greatly reduced the amount of disk writing after the initial production asset build, allowing subsequent builds with a hot cache to finish up to 1.35 minutes faster. A no-op build without minification consistently finished in ~2.4 minutes. With a comprehensive solution for localization in place, we then focused on adding minification.
Out of the box, Webpack includes the terser-webpack-plugin for asset minification. Initially, this plugin seemed to perfectly address our needs. It offered the ability to parallelize minification, cache minified results to speed up subsequent builds, and even extract license comments into a separate file.
When we added this plugin to our Webpack configuration, though, our initial asset build suddenly took over 40 minutes and used up to 57GB of RAM at its peak. We expected the initial build to take longer than subsequent builds and that minification would be costly, but this was alarming. Enabling any form of production source maps also dramatically increased the initial build time by a significant amount. Without the terser-webpack-plugin, the initial production asset build with localizations would finish in ~6 minutes. It seemed like the plugin was adding an unknown bottleneck to our builds, and ad hoc monitoring with htop during the initial production asset build seemed to confirmed our suspicions:
At some points during the minification phase, we appeared to only use a single CPU core. This was surprising to us because we had enabled parallelization in terser-webpack-plugin’s options. To get a better understanding of what was happening, we tried running strace on the main thread to profile the minification phase:
At the start of minification, the main thread spent a lot of time making memory syscalls (mmap and munmap). Upon closer inspection of terser-webpack-plugin’s source code, we found that the main thread needed to load the contents of every asset to generate parallelizable minification jobs for its worker threads. If source maps were enabled, the main thread also needed to calculate each asset’s corresponding source map. These lines explained the flood of memory syscalls we noticed at the start.
Further into minification, the main thread started making recvmsg and write syscalls to communicate between threads. We corroborated these syscalls when we found that the main thread needed to serialize the contents of each asset (and source maps if they were enabled) to send it to a worker thread to be minified. After receiving and deserializing a minification result received from a worker thread, the main thread was also solely responsible for caching the result to disk. This explained the stat, open, and other write syscalls we observed because the Node.js code promises to write the contents. The underlying epoll_wait syscalls then poll to check when the writing finishes so that the promise can be resolved.
The main thread can become a bottleneck when it has to perform these tasks for a lot of assets, and considering our production asset build could produce over 13,200 assets, it was no wonder we hit this bottleneck. To minify our assets, we would have to think of a different way.
We opted to minify our production assets outside of Webpack, in what we call “post-processing”. We split our production asset build into two stages, a Webpack stage and a post-processing stage. The former is responsible for generating and writing localized assets to disk, and the latter is responsible for performing additional processing on these assets, like minification:
For minification, we use the same terser library the terser-webpack-plugin uses. We also baked parallelization and caching into the post-processing stage, albeit in a different way than the plugin. Where Webpack’s plugin reads the file contents on the main thread and sends the whole contents to the worker threads, our parallel-processing jobs send just the file path to the workers. A worker is then responsible for reading the file, minifying it, and writing it to disk. This reduces memory usage and facilitates more efficient parallel-processing. To implement caching, the Webpack stage passes along the list of assets written by the current build to tell the post-processing stage which files are new. Sentinel assets are also excluded from post-processing because they aren’t served to users.
Splitting our production asset builds into two stages does have a potential downside: our Webpack configuration is now expected to output un-minified text for assets. Consequently, we need to audit any third-party plugins to ensure they do not transform the outputted assets in a format that breaks post-processing. Nevertheless, post-processing is well worth it because it allows us to achieve the fast build times we expect for production asset builds.
Bonus: source maps
We don’t just generate assets in under five minutes on average — we also generate corresponding source maps for all of our assets too. Source maps allow engineers to reconstruct the original source code that went into an asset. They do so by maintaining a mapping of the output lines of a transformation, like minification or Webpack bundling, to the input lines. Maintaining this mapping during the transformation process, though, inherently adds time.
Coincidentally, the same localization characteristics that enable localization inlining also enable faster source map generation. As we saw earlier, the only differences between localized assets are the lines containing localization strings. Subsequently, these lines with localization strings are the only differences between the source maps for these localized assets. For the rest of the lines, the source map for one localized asset is equivalently accurate for another because each line is at the same line number between localized assets.
If we were to generate source maps for each localized asset, we would end up repeating resource-intensive work only to result in nearly identical source maps across locales. Instead, we only generate source maps for the sentinel assets the localized assets are derived from. We then use the sentinel asset’s source map for each localized asset derived from it, and accept that the mapping for the lines with localization strings will be incorrect. This greatly speeds up source map generation because we are able to reuse a single source map that applies to many assets.
For the minification transformation that occurs during post-processing, terser accepts a source map alongside the input to be minified. This input source map allows terser to account for prior transformations when generating source mappings for its minification. As a result, the source map for its minified results still maps back to the original source code before Webpack bundling. In our case, we pass terser the sentinel asset’s source map for each localized asset derived from it. This is only possible because we aren’t using terser-webpack-plugin, which (understandably) doesn’t allow mismatched asset/source map pairings.
Through these source map optimizations, we are able to maintain source maps for all assets while only adding ~1.7 minutes to our build time average. Our unique approach can result in up to a 70% speedup in source map generation compared to out-of-the-box options offered by Webpack, a dramatic reduction in the time.
Our journey to achieving fast production builds can be summed up into three principles: reduce, reuse, recycle.
Reduce Reduce the workload on Webpack’s single thread. This goes beyond applying parallelization plugins and implementing better caching. Investigating our builds led us to discover single-threaded bottlenecks like minification, and after implementing our own parallelized post-processing we observed significantly faster build times.
Reuse The more existing work our production build can reuse, the less it has to do. Thanks to the convenient circumstances of our production setup, we are able to reuse source maps and apply them to more than one asset each. This avoids a significant amount of unnecessary work when generating source maps, a time-intensive process.
Recycle When we can’t reuse existing work, figuring out how to recycle it is equally valuable. Deriving localized assets from sentinel assets allows us to recycle the expensive work of producing an asset from an entrypoint, further speeding up builds.
While some implementation details may become obsolete as Webpack and the frontend evolve, these principles will continue to guide us towards faster production builds.
As companies are moving to the cloud, they are finding a need for security tooling to audit and analyze their cloud environments. Over the last few years, various tools have been developed for this purpose. We’ll look at some of them and consider the uses for them. Specifically, we’ll take a close look at G-Scout, a tool I developed while working at NCC Group to look for security misconfigurations in Google Cloud Platform (GCP); and G-Scout Enterprise, a new tool with the same purpose, but tailored to the needs of security engineers at Etsy. We’ll also consider G-Scout Enterprise’s role within an ecosystem of other cloud logging and monitoring tools used at Etsy.
Cloud environments have a convenient feature which you won’t get from on premise servers: they have APIs. It’s similar for all the major cloud providers. They have a REST API which provides information on what services are being used, what resources exist, and how they are configured. An authorized user can call these APIs through a command line tool, or programmatically through a client library.
Those APIs provide information which is useful for security purposes. A classic example is a storage bucket (S3, GCS, etc.) which has been made public. It could be publicly readable, or publicly writable. Since we can use the API to see the permissions on any bucket we own, we can look for misconfigured permissions. So we go through all the API data we have for all our storage buckets, and look for permissions assigned to allUsers, or allAuthenticatedUsers.
Here are some other common examples:
Firewall rules are too permissive.
Unencrypted database connections.
Users have excessive permissions.
Configuration Scanning Tools
Rather than making API calls and processing the data ad hoc, you can create a framework. A tool that will allow you, with a single command, to run various API calls to gather data on diverse resources, and then programmatically look for misconfigurations in that data. And in the end, you can have the tool place the results into a human-readable HTML report which you can browse according to your whims.
Scout 2 does all of the above for Amazon Web Services (AWS). G-Scout was created with a similar solution in mind as Scout 2, but for GCP. After Scout 2 there have followed plenty of other examples. Some, like G-Scout, have been open source, and others are available for purchase.
These tools continue to evolve. It is becoming increasingly common for companies to use more than one cloud provider. With this trend we’ve seen the creation of multi-cloud tools. Scout Suite has replaced Scout 2. Inspec supports AWS, Azure, and GCP.
And some of them have added features. Forseti Inventory stores the data collected in a SQL database (I’ve moved G-Scout in a similar direction, as we’ll see later). Forseti Enforcer will actually make changes to match policies.
These features are useful, but not so much to a consultant, since a consultant shouldn’t want any permissions aside from viewer permissions. Scout 2 was designed for consulting. The user can get viewer permissions, run the tool, and leave no trace. Forseti, on the other hand, requires Organization Admin permissions, and creates a database and other resources within the organization that is being audited.
Difficulties With G-Scout
But the same basic functionality remains at the core of each of these tools. When it came to G-Scout, that core functionality worked well for smaller companies, or those less committed to GCP. But when there are hundreds of projects, thousands of instances, and many other resources, it becomes difficult to go through the results.
Adding to this difficulty is the presence of false positives. Any automated tool is going to turn up false positives. Context may make something that seems like a finding at first glance, instead turn out to be acceptable. To return to our public storage bucket example, there are some cases where the content in the bucket is intended to be public. You can even serve a simple HTML website from a storage bucket. So it tends to fall to a human to go through and figure out which are false positives. Since it takes time to fix real findings, and the false positives don’t go away, running the tool frequently to see what’s new becomes untenable.
Finally, at Etsy, many of the findings G-Scout would turn up had already been found by other means, which we will explore a bit below.
We have a tool called Reactor. There is a stackdriver log sink for the organization, and those logs (with filters applied) go to a PubSub topic. There’s a cloud function that subscribes to that topic, and when it finds logs that match any of a further set of filters (the alerting rules) then it triggers an alert.
So for example, if someone makes a storage bucket public, an alert will trigger as soon as the corresponding stackdriver log is generated, rather than waiting for someone to run G-Scout at some point.
Here’s a partial example of a stackdriver log. As an API call to check IAM permissions would, it has all the information we need to trigger an alert. We see the user that granted the permission (in this case a service account). And below the fold we would see which role was assigned and which user it was assigned to.
Another point where we are alerting on misconfigurations is resource creation. We use Terraform for infrastructure as code. Before a Terraform apply is run, we have a series of unit tests that will be run by the pipeline. The unit tester runs tests for many of the same events which we alert on with the stackdriver logs. This includes the common example of a bucket being made public.
This is another process that is not so useful for a security consultant. But it’s better to catch misconfigurations in this way, than in the way Scout 2 or G-Scout would catch them, since this will prevent them from ever being implemented!
So we have what I’ll call a three-pronged approach to catching misconfigurations in GCP. These are the three prongs:
Terraform unit testing that is meant to catch misconfigurations before they go into effect.
Stackdriver alerting that occurs when the resource is created or changed (whether those changes are made through Terraform or not).
And in case anything gets through the first two, we have the point in time audit of all GCP resources provided by G-Scout Enterprise.
In summary, G-Scout’s traditional purpose was proving minimally useful. It was difficult to make good use of the G-Scout reports. And as we’ve seen, the first two prongs will usually catch misconfigurations first. So I moved away from G-Scout, and toward a new creation: G-Scout Enterprise.
The fundamental change is to replace the HTML report with a BigQuery data collection. In fact, at its core, G-Scout Enterprise is very simple. It’s mostly just something that takes API data and puts it into BigQuery. Then other systems can do with that data as they please. The rules that will trigger alerts can be written in our alerting system like any other alerts we have (though they can also easily be written in Python within G-Scout Enterprise). We are now putting all of our other data into BigQuery as well, so it’s all connected.
Users can query any of the tables, each of which corresponds to one GCP API endpoint. G-Scout Enterprise tables can be joined – and they can be joined to our other data sources as well. And we can be very specific: like looking for all roles where email@example.com is a member, without enshrining it in our ruleset, because we can run queries through the BigQuery console. Or we can run queries in the command line, with helper functions that allow us to query with Python rather than SQL.
We can make comparisons and track changes over time. It can also provide context to other alerts. For example, if we have an IP address from an SSH alert, we can get information about the instance which owns that IP address, such as what service account it has, or what Chef role it has.
Or for instance, the following, more complicated scenario:
We run Nessus. Nessus is an automated vulnerability scanner. It has a library of vulnerabilities it looks for by making network requests. You give it a list of IPs and it goes through them all. We now have it running daily. With a network of any size the volume of findings will quickly become overwhelming. Many of them are informational or safely ignored. But the rest need to be triaged, and addressed in a systematic way.
Not all Nessus findings are created equal. The same vulnerability on two different instances may be much more concerning on one than the other: if one is exposed to the internet and the other is not; if one is working with PII and the other is not; if one is in development and the other in production, and so on. Most of the information which determines how concerned we are with a vulnerability can be found among the collection of data contained in G-Scout Enterprise. This has simplified our scanning workflow. Since we can do network analysis with the data in G-Scout Enterprise, we can identify which instances are accessible from where. That means we don’t have to scan from different perspectives. And it has improved the precision of our vulnerability triaging, since there is so much contextual data available.
So we go through the following process:
Enumerate all instances in our GCP account.
Discard duplicate instances (instances from the same template, e.g. our many identical web server instances).
Run the Nessus scan and place the results into BigQuery.
Create a joined table of firewall rules and instances which they apply to (matching tags).
Take various network ranges (0.0.0.0/0, our corporate range, etc.), and for each firewall rule see if it allows traffic from that source.
For instances with firewall rules that allow ingress from 0.0.0.0/0, see if the instance has a NatIP or is behind an external load balancer.
Check whether the project the instance lives in is one of the projects classified as sensitive.
Compute and assign scores according to the previous steps
And then we save the results into BigQuery. That gives us historical data. We can see if we are getting better or worse. We can see if we have certain troublemaker projects. We can empower our patch management strategy with a wealth of data.
That leaves us with a few main lessons gained from adapting G-Scout to Etsy:
It’s useful to store cloud environment info in a database. That makes it easier to work with, and easier to integrate with other data sources.
The needs of a consultant are different from the needs of a security engineer. Although there is crossover, different tools may better fit the needs of one or the other.
The three pronged alerting approach described above provides a comprehensive solution for catching security misconfigurations in the Cloud.
One last note is that we have plans to open source G-Scout Enterprise in the coming months.
In late May of 2018, Etsy internally released an Engineering Career Ladder. Today, we’re sharing that ladder publicly and detailing why we decided to build it, why the content is what it is, and how it’s been put into use since its release.
A career ladder is a tool to help outline an engineer’s path for growth within a company. It should provide guidance to engineers on how to best take on new responsibilities, and allow their managers to assess and monitor performance and behavior. A successful career ladder should align career progression with a company’s culture, business goals, and guiding principles and act as a resource to guide recruiting, training, and performance assessments.
Etsy has had several forms of a career ladder before this iteration. The prior career ladders applied to all Etsy employees, and had a set of expectations for every employee in the same level across all disciplines. Overall, these previous ladders worked well for Etsy as a smaller company, but as the engineering team continued to grow we found the content needed updating to meet practical expectations, as the content in the ladder started to feel too broad and unactionable.
As a result, we developed this career ladder, specific to engineering, to allow us to be more explicit with those expectations and create a unified understanding of what it means to be an engineer at a certain level at Etsy. This ladder has been in place for over a year now, and in that time we’ve gone through performance reviews, promotion cycles, lots of hiring, and one-on-one career development conversations. We’re confident that we’ve made a meaningful improvement to engineering career development at Etsy and hope that releasing this career ladder publicly can help other companies support engineering career growth as well.
Designing the Etsy Engineering Career Ladder
We formed a working group focused on creating a new iteration of the career ladder comprised of engineers and engineering managers of various levels. The working group included Miriam Lauter, Dan Auerbach, and Jason Wain, and me. We started by exploring our current company-wide career ladder, discussing its merits and limitations, and the impact it had on engineering career development. We knew that any new version needed to be unique to Etsy, but we spent time exploring publicly available ladders of companies who had gone through a similar process in an effort to understand both tactical approaches and possible formats. Many thanks specifically to Spotify, Kickstarter, Riot Games, and Rent the Runway for providing insight into their processes and outcomes. Reviewing their materials was invaluable.
We decided our first step was to get on the same page as to what our goals were, and went through a few exercises resulting in a set of tenets that we felt would drive our drafting process and provide a meaningful way to evaluate the efficacy of the content. These tenets provided the foundation to our approach for developing the ladder.
Support meaningful career growth for engineers
Our career ladder should be clear enough, and flexible enough, to provide direction for any engineer at the company. We intended this document to provide actionable steps to advance your career in a way that is demonstrably impactful. Ideally, engineers would use this ladder to reflect on their time at Etsy and say “I’ve developed skills here I’ll use my entire career.”
Unify expectations across engineering
We needed to build alignment across the entire engineering department about what was required to meet the expectations of a specific level. If our career ladder were too open to interpretation it would cause confusion, particularly as it relates to the promotion process. We wanted to ensure that everyone had a succinct, memorable way to describe our levels, and understand exactly how promotions happen and what is expected of themselves and their peers.
Recognize a variety of valid career paths
Whether you’re building machine learning models or localizing our products, engineering requires skills across a range of competencies, and every team and project takes individuals with strengths in each. We wanted to be explicit about what we believe about the discipline, that valid and meaningful career paths exist at all levels for engineers who bring differences of perspectives and capabilities, and that not everyone progresses as an engineer in the same way. We intended to codify that we value growth across a range of competencies, and that we don’t expect every person to have the same set of strengths at specific points in their career.
Limit room for bias in how we recognize success
A career ladder is one in a set of tools that can help an organization mitigate potential bias. We needed to be thoughtful about our language, ensuring that it is inclusive, objective, and action oriented. We knew the career ladder would be used as basis for key career advancement moments, such as hiring and promotions, so developing a clear and consistent ladder was critical for mitigating potential bias in these processes.
Developing the Etsy Engineering Career Ladder
With these tenets in place, we had the first step towards knowing what was necessary for success. In addition to creating draft ladder formats, we set about determining how we could quantify the improvements that we were making. We outlined key areas where we’d need to directly involve our stakeholders, including engineering leadership, HR, Employee Resource Groups, and of course engineers. We made sure to define multiple perspectives for which the ladder should be a utility; e.g. an engineer looking to get promoted, a manager looking to help guide an engineer to promotion, or a manager who needed to give constructive performance feedback.
Implicit biases can be notoriously difficult to acknowledge and remove from these processes, and we knew that in order to do this as best as possible we’d need to directly incorporate feedback from many individuals, both internal and external, across domains and disciplines, and with a range of perspectives, to assure that we were building those perspectives into the ladder.
Our tactics for measuring our progress included fielding surveys and requests for open feedback, as well as direct 1:1 in-depth feedback sessions and third party audits to ensure our language was growth-oriented and non-idiomatic. We got feedback on structure and organization of content, comprehension of the details within the ladder, the ladder’s utility when it came to guiding career discussions, and alignment with our tenets.
The feedback received was critical in shaping the ladder. It helped us remove duplicative, unnecessary, or confusing content and create a format that we thought best aligned with our stated tenets and conveyed our intent.
And finally, the Etsy Engineering Career Ladder
You can find our final version of the Etsy Engineering Career Ladder here.
The Etsy Engineering Career Ladder is split into two parts: level progression and competency matrix. This structure explicitly allows us to convey how Etsy supports a variety of career paths while maintaining an engineering-wide definition of each level. The level progression is the foundation of the career ladder. For each level, the ladder lays out all requirements including expectations, track record, and competency guidelines. The competency matrix lays out the behaviors and skills that are essential to meeting the goals of one’s role, function, or organization.
Each section within the level progression provides a succinct definition of the requirements for an engineer with that title. It details a number of factors, including the types of problems an engineer is solving, the impact of their work on organizational goals and priorities and how they influence others that they work with. For levels beyond Engineer I, we outline an expected track record, detailing achievements over a period of time in both scale and complexity. And to set expectations for growth of competencies, we broadly outline what levels of mastery an engineer needs to achieve in order to be successful.
If the level progression details what is required of an engineer at a certain level, competencies detail how we expect they can meet those expectations. We’ve outlined five core competency areas:
For each of these five competency areas, the competency matrix provides a list of examples that illustrate what it means to have achieved various levels of mastery. Mastery of a competency is cumulative — someone who is “advanced” in problem solving is expected to retain the skills and characteristics required for an “intermediate” or “beginner” problem solver.
Evaluating our Success
We internally released this new ladder in May of 2018. We did not immediately make any changes to our performance review processes, as it was critical to not change how we were evaluating success in the middle of a cycle. We merely released it as a reference for engineers and their managers to utilize when discussing career development going forward. When our next performance cycle kicked off, we began incorporating details from the ladder into our documentation and communications, making sure that we were using it to set the standards for evaluation.
Today, this career ladder is one of the primary tools we use for guiding engineer career growth at Etsy. Utilizing data from company-wide surveys, we’ve seen meaningful improvement in how engineers see their career opportunities as well as growing capabilities for managers to guide that growth.
Reflecting on the tenets outlined at the beginning of the process allows us to look back at the past year and a half and recognize the change that has occurred for engineers at Etsy and evaluate the ladder against the goals we believed would make it a success. Let’s look back through each tenet and see how we accomplished it.
Support meaningful career growth for engineers
While the content is guided by our culture and Guiding Principles, generally none of the competencies are Etsy-specific. The expectations, track record, and path from “beginner” to “leading expert” in a competency category are designed to show the growth of an engineer’s impact and recognize accomplishments that they can carry throughout their career, agnostic of their role, team, or even company.
The competency matrix also allows us to guide engineer career development within a level. While a promotion to a new level is a key milestone that requires demonstration of meeting expectations over time, advancing your level of mastery by focusing on a few key competencies allows engineers to demonstrate continual growth, even within the same level. This encourages engineers and their managers to escape the often insurmountable task of developing a plan to achieve the broader set of requirements for the next promotion, and instead create goals that help them get there incrementally.
Compared to our previous ladder, the path to Staff Engineer is no longer gated by the necessity to increase one’s breadth. We recognized that every domain has significantly complex, unscoped problems that need to be solved, and that we were limiting engineer growth by requiring those who were highly successful in their domain to expand beyond it. Having expectations outlined as they are now allows engineers the opportunity to grow by diving more deeply into their current domains.
Unify expectations across engineering
The definition for each level consists only of a few expectations, a track record, and guidelines for level of mastery of competencies. It is easy to parse, and to refer back to to get a quick understanding of the requirements. With a little reflection, it should be easy to describe how any engineer meets the three to five expectations of their level.
Prior to release, we got buy-in from every organizational leader in engineering that these definitions aligned with the reality of the expectations of engineers in their org. Since release we’ve aligned our promotion process to the content in the ladder. We require managers to outline how a candidate has met the expectations over the requisite period stated in the track record for their new level, and qualify examples of how they demonstrate the suggested level of mastery for competencies.
Recognize a variety of valid career paths
We ask managers to utilize the competencies document with their reports’ specific roles in mind when talking about career progression. Individual examples within the competency matrix may feel more or less applicable to individual roles, such as a Product Engineer or a Security Engineer, and this adaptability allows per-discipline growth while still aligning with the behaviors and outcomes we agree define a level of mastery. A small set of example skills is provided for each competency category that can help to better contextualize the application of the competencies in various domains. Additionally, we intentionally do not detail any competencies for which success is reliant on your team or organization.
Allowing managers to embrace the flexibility inherent in the competency matrix and its level of mastery system has allowed us to universally recognize engineer growth as it comes in various forms, building teams that embrace differences and value success in all its shapes. Managers can grow more diverse teams, for instance, by being able to recognize engineering leaders who are skilled domain experts, driving forward technical initiatives, and other engineering leaders who are skilled communicators, doing the glue work and keeping the team aligned on solving the right problems. We recognize that leadership takes many forms, and that is reflected in our competency matrix.
Limit room for bias in how we recognize success
The career ladder is only a piece of how we can mitigate potential bias as an organization. There are checks and balances built into other parts of Etsy’s human resources processes and career development programs, but since a career ladder plays such a key role in shaping the other processes, we approached this tenet very deliberately.
The competencies are not personality based, as we worked to remove anything that could be based on subjective perception of qualities or behaviors, such as “being friendly.” All content is non-idiomatic, in an effort to reduce differences in how individuals will absorb or comprehend the content. We also ensured that the language was consistent between levels by defining categories for each expectation. For instance, defining the expected complexity of the problems engineers solve per level allowed us to make sure we weren’t introducing any leaps in responsibility between levels that couldn’t be tied back to growth in the previous level.
We also explicitly avoided any language that reads as quantifiable (e.g. “you’ve spoken at two or more conferences”) as opportunities to achieve a specific quantity of anything can be severely limited by your role, team, or personal situation, and can lead to career advice that doesn’t get at the real intent behind the competency. Additionally, evaluation of an individual against the ladder, for instance as part of a promotion, is not summarized in numbers. There is no score calculation or graphing an individual on a chart, nor is there an explicit number of years in role or projects completed as an expectation. While reducing subjectivity is key to mitigating potential bias, rigid numerical guidelines such as these can actually work against our other tenets by not allowing sufficient flexibility given an individual’s role.
Most importantly, the ladder was shaped directly through feedback from Etsy engineers, who have had direct personal experiences with how their individual situations may have helped or hindered their careers to draw on.
We’re really passionate about supporting ongoing engineer career growth at Etsy, and doing it in a way that truly supports our mission. We believe there’s a path to Principal Engineer for every intern and that this ladder goes a long way in making that path clear and actionable. We hope this ladder can serve as an example, in addition to those we took guidance from, to help guide the careers of engineers everywhere.
If you’re interested in growing your career with us, we’d love to talk, just click here to learn more.
One of the most fundamental principles of information security is the principle of least privilege. This principle states that users should only be given the minimal permissions necessary to do their job. A corollary of the principle of least privilege is that users should only have those privileges while they are actively using them. For especially sensitive actions, users should be able to elevate their privileges within established policies, take sensitive actions, and then return their privilege level to normal to resume normal usage patterns. This is sometimes called privilege bracketing when applied to software, but it’s also useful for human users.
Following this principle reduces the chance of accidental destructive actions due to typos or misunderstandings. It may also provide some protection in case the user’s credentials are stolen, or if the user is tricked into running malicious code. Furthermore, it can be used as a notice to perform additional logging or monitoring of user actions.
In Unix this takes the form of the su command, which allows authorized users to elevate their privileges, take some sensitive actions, and then reduce their permissions. The sudo command is an even more fine-grained approach with the same purpose, as it will elevate privileges for a single command.
Some cloud providers have features that allow for temporary escalation of privileges. Authorized users can take actions with a role other than the one which is normally assigned to them. The credentials used to assume a role are temporary, so they will expire after a specified amount of time. However, we did not find a built-in solution to achieve the same functionality in Google Cloud Platform (GCP).
Apotheosis is a tool that is meant to address the issues above. The word apotheosis means the elevation of someone to divine status. It’s possible, and convenient, to give users permanent “godlike” permissions, but this is a violation of the principle of least privilege. This tool will allow us to “apotheosize” users, and then return them to a “mortal” level of privilege when their job duties no longer require additional privileges.
Users or groups can be given “actual permissions” and “eligible permissions”. For example, a user who currently has the owner role may instead be given only the viewer role, and we will call that their “actual permissions”. Then we can give them “eligible permissions” of owner, which will come in the form of the service account token creator role on a service account with the editor or organization admin role.
For this user to elevate their privileges, the Apotheosis command line program will use their GCP credentials to call the REST API to create a short-lived service account token. Then, using that token, Apotheosis will make another REST API call which will grant the requested permissions to the user. Or, alternatively, the permissions may be granted to a specified third party, allowing the Apotheosis user to leverage their eligible permissions to grant actual permissions to another entity. The program will wait for a specified amount of time, remove the requested permissions, and then delete the short-lived service account token.
This process has the following advantages:
It requires no additional access controls or centralized server actions. There is no possibility of compromising the program since it is local and only capable of escalating to the level of privilege which users are already allowed in the GCP Identity and Access Management (IAM) configuration.
The user is only required to enter one command in their terminal. It looks like this:apotheosis -m user:firstname.lastname@example.org -r roles/editor -d 600 --resource some-project. Or to use the defaults, just apotheosis.
Any permissions will be granted by the designated service account. This allows for logging that service account’s IAM activity, and alerting on any troubling events in regards to that activity.
Some additional features which may be added to Apotheosis are contingent on the launch of other features, such as conditional IAM. Conditional IAM will allow the use of temporal restrictions on IAM grants, which will make Apotheosis more reliable. With conditional IAM, if Apotheosis is interrupted and does not revoke the granted permissions, they will expire anyway.
The ability to allow restricted permissions granting will be a useful IAM feature as well. Right now a user or service account can be given a role like editor or organization admin, and then can grant any other role in existence. But if it were possible to allow granting a predefined list of roles, that would make Apotheosis useful for a larger set of users. As it is now, Apotheosis is useful for users who have the highest level of eligible privilege, since their access to the Apotheosis service account gives them all the privileges of that service account. That is, the scope of those privileges can be limited to a particular project, folder, or organization, but cannot be restricted to a limited set of actions. At the moment that service account must have one of the few permissions which grant the ability to assign any role to any user.
Requiring two-factor authentication when using the short-lived service account token feature on a particular service account would be another useful feature. This would require an Apotheosis user to re-authenticate with another factor when escalating privileges.
Apotheosis is open source and can be found on Github.
Aesthetic style is key to many purchasing decisions. When considering an item for purchase, buyers need to be aligned not only with the functional aspects (e.g. description, category, ratings) of an item’s specification, but also its aesthetic aspects (e.g. modern, classical, retro) as well. Style is important at Etsy, where we have more than 60 million items and hundreds of thousands of them can differ by style and aesthetic. At Etsy, we strive to understand the style preferences of our buyers in order to surface content that best fits their tastes.
Our chosen approach to encode the aesthetic aspects of an item is to label the item with one of a discrete set of “styles” of which “rustic”, “farmhouse”, and “boho” are examples. As manually labeling millions of listings with a style class is not feasible – especially in a marketplace that is ever changing, we wanted to implement a machine learning model that best predicts and captures listings’ styles. Furthermore, in order to serve style-inspired listings to our users, we leveraged the style predictor to develop a mechanism to forecast user style preferences.
Style Model Implementation
For this task, the style labels are one of the classes that have been identified by our merchandising experts. Our style model is a machine learning model which, when given a listing and its features (text and images), can output a style label. The style model was designed to not only output these discrete style labels but also a multidimensional vector representing the general style aspects of a listing. Unlike a discrete label (“naval”, “art-deco”, “inspirational”) which can only be one class, the style vector encodes how a listing can be represented by all these style classes in varying proportions. While the discrete style labels can be used in predictive tasks to recommend items to users from particular style classes (say filtering recommended listings to a user from just “art-deco”), the style vector is supposed to serve as a machine learning signal into our other recommendation models. For example, on a listing page on Etsy, we recommend similar items. This model can now surface items that are not only functionally the same (“couch” for another “couch”) but can potentially recommend items that are instead from the same style (“mid-century couch” for a “mid-century dining table”).
The first step in building our listing style prediction model was preparing a training data set. For this, we worked with Etsy’s in-house merchandising experts to identify a list of 43 style classes. We further leveraged search visit logs to construct a “ground truth” dataset of items using these style classes. For example, listings that get a click, add to cart or purchase event for the search query “boho” are assigned the “boho” class label. This gave us a large enough labeled dataset to train a style predictor model.
Once we had a ground truth dataset, our task was to build a listing style predictor model that could classify any listing into one of 43 styles (it is actually 42 styles and a ‘everything else’ catch all). For this task, we used a two layer neural network to combine the image and text features in a non-linear fashion. The image features are extracted from the primary image of a listing using a retrained Resnet model. The text features are the TF-IDF values computed on the titles and tags of the items. The image and text vectors are then concatenated and fed as input into the neural network model. This neural network model learns non-linear relationships between text and image features that best predict a listings style. This Neural Network was trained on a GPU machine on Google Cloud and we experimented with the architecture and different learning parameters until we got the best validation / test accuracy.
As described above, the style model helps us extract low-dimension embedding vectors that capture this stylistic information for a listing, using the penultimate layer of the neural network. We computed the style embedding vector using the style model for all the listings in Etsy’s corpus.
Given these listing style embeddings, we wanted to understand users’ long-term style preferences and represent it as a weighted average of 42 articulated style labels. For every user, subject to their privacy preferences, we first gathered the entire history of “purchased”, “favorited”, “clicked” and “add to cart” listings in the past three months. From all these listings that a user interacted with, we combined their corresponding style vectors to come up with a final style representation for each user (by averaging them).
Building Style-aware User Recommendations
There are different recommendation modules on Etsy, some of which are personalized for each user. We wanted to leverage user style embeddings in order to provide more personalized recommendations to our users. For recommendation modules, we have a two-stage system: we first generate a candidate set, which is a probable set of listings that are most relevant to a user. Then, we apply a personalized ranker to obtain a final personalized list of recommendations. Recommendations may be provided at varying levels of personalization to a user based on a number of factors, including their privacy settings.
In this very first iteration of user style aware recommendations, we apply user style understanding to generate a candidate set based on user style embeddings and their latest interacted taxonomies. This candidate set is used for Our Picks For You module on the homepage. The idea is to combine the understanding of a user’s long time style preference with his/her recent interests in certain taxonomies.
This work can be broken down into three steps:
For each user, obtain top three styles and three latest taxonomies.
Given user style embeddings, we take top 3 styles with the highest probability to be the “predicted user style”. Latest taxonomies are useful because they indicate users’ recent interests and shopping missions.
For each (taxonomy, style) pair, generate 100 listings.
Given a taxonomy, sort all the listings in this taxonomy by the different style prediction scores for different classes, high to low. We take the top 100 listings out of these.
For each user, remove invalid (taxonomy, style) pairs.
Taxonomy, style validation is to check whether a style makes sense for a certain taxonomy. eg. Hygge is not a valid style for jewelry.
For each user, aggregate all listings generated by each valid style & taxonomy pair and take top 200 listings with the highest average purchase and favorite rate.
These become the style based recommendations for a user.
We were extremely interested to use our style model to answer questions about users sense of style. Our questions ranged from “How are style and taxonomy related? Do they have a lot in common?”, “Do users care about style while buying items?” to “How do style trends change across the year?”. Our style model enables us to answer at least some of these and helps us to better understand our users. In order to answer these questions and dig further we leveraged our style model and the generated embeddings to perform analysis of transaction data.
Next, we looked at the seasonality effect behind shopping of different styles on Etsy. We began by looking at unit sales and purchase rates of different styles across the year. We observed that most of our styles are definitely influenced by seasonality. For example, “Romantic” style peaks in February because of Valentines Day and “Inspirational” style peaks during graduation season. We tested the unit sales time series of different styles for statistical time series-stationarity test and found that the majority of the styles were non-stationary. This signifies that the majority of styles show different shopping trends throughout the year and don’t have constant unit sales throughout the year. This provided further evidence that users tastes show different trends across the year.
Using the style embeddings to study user purchase patterns not only provided us great evidence that users care about style, but also inspired us to further incorporate style into our machine learning products in the future.
Etsy is a marketplace for millions of unique and creative goods. Thus, our mission as machine learning practitioners is to build pathways that connect the curiosity of our buyers with the creativity of our sellers. Understanding both listing and user styles is another one of our novel building blocks to achieve this goal.
For further details into our work you can read our paper published in KDD 2019.
Authors: Aakash Sabharwal, Jingyuan (Julia) Zhou & Diane Hu
Etsy has an uncontrolled inventory; unlike many marketplaces, we offer an unlimited array of one-of-a-kind items, rather than a defined set of uniform goods. Etsy sellers are free to list any policy-compliant item that falls within the three broad buckets of craft supplies, handmade, and vintage. Our lack of standardization, of course, is what makes Etsy special, but it also makes learning about our inventory challenging. That’s where structured data comes in.
Structured vs. Unstructured Data
Structured data is data that exists in a defined relationship to other data. The relation can be articulated through a tree, graph, hierarchy, or other standardizedschema and vocabulary. Conversely, unstructured data does not exist within a standardized framework and has no formal relationship to other data in a given space.
For the purposes of structured data at Etsy, the data are the product listings, and they are structured according to our conception of where in the marketplace they belong. That understanding is expressed through the taxonomy.
Etsy’s taxonomy is a collection of hierarchies comprised of 6,000+ categories (ex. Boots), 400+ attributes (ex. Women’s shoe size), 3,500+ values (ex. 7.5), and 90+ scales (ex. US/Canada). These hierarchies form the foundation of 3,500+ filters and countless category-specific shopping experiences on the site. The taxonomy imposes a more controlled view of the uncontrolled inventory — one that engineers can use to help buyers find what they are looking for.
Building the Taxonomy
The Etsy taxonomy is represented in JSON files, with each category’s JSON containing information about its place in the hierarchy and the attributes, values, and scales for items in that category. Together, these determine what questions will be asked of the seller for listings in that category (Figure A, Box 1), and what filters will be shown to buyers for searches in that category (Figure A, Box 2).
The taxonomists at Etsy are able to alter the taxonomy hierarchies using an internal tool. This tool supports some unique behaviors of our taxonomy, like inheritance. This means that if a category has a particular filter, then all of its subcategories will inherit that filter as well.
Gathering Structured Data: The Seller Perspective
One of the primary ways that we currently collect structured data is through the listing creation process, since that is our best opportunity to learn about each listing from the person who is most familiar with it: the seller!
Sellers create new listings using the Shop Manager. The first step in the listing process is to choose a category for the listing from within the taxonomy. Using auto-complete suggestions, sellers can select the most appropriate category from all of the categories available.
At this stage in the listing creation process, optional attribute fields appear in the Shop Manager. This is also enabled by the taxonomy JSON, in that the fields correspond with the category selected by the seller (see Figure A, Box 1). This behavior ensures that we are only collecting relevant attribute data for each category and simplifies the process for sellers. Promoting this use of standardized data also reduces the need for overloaded listing titles and descriptions by giving sellers a designated space to tell buyers about the details of their products. Data collected during the listing creation process appears on the listing page, highlighting for the buyer some of the key, standardized details of the listing.
Making Use of Structured Data: The Buyer Perspective
Much of the buyer experience is a product of the structured data that has been provided by our sellers. For instance, a given Etsy search yields category-specific filters on the left-hand navigation of the search results page.
Those filters should look familiar! (see Figure D) They are functions of the taxonomy. The search query gets classified to a taxonomy category through a big data job, and filters affiliated with that category are displayed to the user (see Figure F below). These filters allow the buyer to narrow down their search more easily and make sense of the listings displayed.
Structuring Unstructured Data
There are countless ways of deriving structured data that go beyond seller input. First, there are ways of converting unstructured data that has already been provided, like listing titles or descriptions, into structured data. Also, we can use machine learning to learn about our listings and reduce our dependence on seller input. We can, for example, learn about the color of a listing through the image provided; we can also infer more nuanced data about a listing, like its seasonality or occasion.
We can continue to measure the relevance of our structured data through metrics like the depth of our inventory categorization within our taxonomy hierarchies and the completeness of our inventory’s attribution.
All of these efforts allow us to continue to build deeper category-specific shopping experiences powered by structured data. By investing in better understanding our inventory, we create deeper connections between our sellers and our buyers.
I secretly like seeing people’s surprise when I told them that I chose to intern at Etsy because it was the only company that asked for a cover letter. I enjoyed every second of filling out my Etsy software engineering internship application because I felt like I was really telling my story to a company that cared about my whole self. I interned at Etsy during summer 2016 and started working full-time after I graduated from college in 2017. The human touch embedded in Etsy’s engineering culture, business strategy and company vision is still the number one thing I am proud of.
Over the past three years, I have gotten many questions about what it’s like to intern and have my first job out of college at Etsy. It always gives me a warm feeling when students are curious and excited about careers at Etsy, and I think it’s time we give this question answers that will live on the interweb.
This past winter, I met five interns that Etsy hosted for WiTNY (Women in Technology and Entrepreneurship in New York)’s Winternship program. At the end of their three-week internships, they were super excited to share their experiences. One of the winterns, Nia Laureano, wrote a fantastic recap of her time at Etsy, and I thought it would be a great way to start sharing the Etsy internship experience!
Inventing a Process: Five Interns Navigate a Complex Problem Thanks to Etsy’s Relentlessly Human Touch
by Nia Laureano
Interning at Etsy is a unique experience because so much about Etsy’s identity has to be understood in order to move forward with any sort of work. For three weeks in January, a team of four girls and I joined the Etsy family as interns and were tasked with solving an issue being faced by a product team that helps the buyers.
Coming into our first day, the details of our task were overwhelmingly foreign to us. The subject we were dealing with was Etsy’s listing page. It’s a complicated page, due to the fact that 60 million listings exist on Etsy and they are all vastly different. When engineers make changes to the listing page, it is difficult to test their code against every possible variation of the page that exists. Sometimes, a variation slips from their mind — they forget to account for it, which could potentially cause the page to break when they push code. This is what engineers call an edge case, and our job was to create a tool that allows Etsy engineers to test for edge cases more thoroughly. Specifically, we were asked to create a referencefor them to easily find listings that match different criteria and variations to test code against. But solving a project that we barely understood ourselves seemed daunting, if not impossible.
The entirety of our first week was spent immersing ourselves in the context of this world we were working in. We strolled through the typical workflow of an Etsy engineer, trying to imagine where our solution would fit neatly into the puzzle. We spoke to engineers about their frustrations to get to the root of their needs. We became engineers by being thrusted into the process of pushing code to Etsy’s repository. We couldn’t commit to our craft without first understanding how these employees live and work; then we had to imagine what we could do to make their world better.
After interviewing several engineers, we realized that they each had their own ways of testing for edge cases. “I just have two folders of bookmarks that have some links in them,” said one engineer. “But I’m not sure what other people use.” It was surprising to hear that engineers weren’t sure what other people on their team were doing. We realized, at this point, that the problem wasn’t a faulty process — there was no process to begin with. It was up to us to invent a process, or at least establish a basic standard when it comes to testing for edge cases.
In ideation, the solutions we envisioned ranged dramatically. Something as basic as a spreadsheet would have been helpful, but we also dreamed bigger. We thought about creating an automated Etsy shop that auto-generates listings that represent the edge cases that needed to be tested. We wanted to create something ambitious, but it also had to be something we could attain in three weeks. Ultimately, we focused on creating a solution that would deliver on three crucial needs of our engineers: structure, convenience and confidence.
Structure. While some engineers relied on their own bookmarks or spreadsheets to keep track of edge cases, some relied on sheer memory, or asking their coworkers via Slack. Testing for something that could potentially break the listing page, we realized, shouldn’t be such a structureless process. Our solution needed to provide an element of uniformity; it needed to eliminate that glaring unawareness about what other teammates were doing. It needed to be a unifier.
Convenience. In order to make a tool that was accessible and easy to use, we needed to identify and understand the environment in which engineers complete the bulk of their work, because that’s where we would want our tool to live. We quickly noticed one common thread woven through the workflow of not only Etsy’s engineers, but the company as a whole: our messaging platform, Slack. We observed that so much important work at Etsy is already accomplished via Slack; it’s where employees collaborate and even push code. It made perfect sense for our solution to be integrated within the environment that was already so lived-in.
Confidence. Bugs are inevitable, but our engineers deserve to feel confident that the code they are pushing is as clean as it can be. The more edge cases they can test for, the more certain they can feel that their code is quality and fully functional. Therefore, our solution had to be thorough and reliable; it had to be something engineers could trust.
After three weeks, our project was completed in two phases. Our first phase was focused on creating a spreadsheet. This was the skeleton of our final product, which mirrored the anatomy of the listing page itself. To build this, we broke down the different components of the listing page and identified all of the variations that could occur within those components. Then, we spent several days creating almost one hundred of our own listings on Etsy that represented each of those variations. We ended up with a thorough, intuitively structured catalog of edge cases which can now be accessed by anyone at Etsy who needs it.
The second phase of our project was a Slack-integrated bot. Using our spreadsheet as a backbone, we aimed to design a bot that can retrieve edge cases on command via Slack. Engineers can input commands that return single, multiple, or all edge cases they may be looking for. Due to our time constraint, we were only able to create a bot that utilizes test data, but we hope to see a future iteration that fully integrated with our spreadsheet.
A universe of terminology and culture had to be packed into our brains in order to accomplish what we did in three weeks. Yet, we somehow felt so seamlessly integrated into Etsy’s ecosystem from day one, thanks to the friendly and enthusiastic nature of everyone around us. We were never afraid to ask questions, because no one ever talked downto us or made us feel inferior. There are no mechanisms in place at Etsy that make power dynamics apparent, not even from the perspective of an intern.
Our project was completed not because of crash courses in PHP or because we overloaded on cold brew; it was thanks to the people who nurtured us along the way. It was the prospect of creating something that could make a lasting impact on a company we loved that motivated us. Etsy’s relentlessly human touch makes even the smallest of projects feel meaningful, and it can turn three weeks into an unforgettable experience that I will never stop feeling passionate about.
A note about our internship & our organization:
WiTNY (Women in Technology and Entrepreneurship in New York) is a collaborative initiative between Cornell Tech x CUNY designed to inspire young women to pursue careers in technology. WiTNY offers workshops and program that teach important skills and provide real work experience.
The Winternship program is a paid, three-week, mini-internship for first and second-year undergraduate students at CUNY schools, during their January academic recess. Etsy is one of many companies who participated in the Winternship program this year, taking a team of five young women and giving them a challenging project to complete while also teaching them about the different roles within a tech company.
We all know how exciting it is to build new products, the thrill of a pile of new ideas waiting to be tested, new customers to reach, knotty problems to solve, and dreams of upward-sloping graphs. But what happens when it is no longer aligned with the trajectory of the company. Often, the product, code, and infrastructure become a lower priority, while the team moves on to the next exciting new venture. In 2018, Etsy sunset Etsy Wholesale, Etsy Studio, and Etsy Manufacturing, three customer-facing products.
In this blog post, we will explore how we sunset these products at Etsy. This process involves a host of stakeholders including marketing, product, customer support, finance and many other teams, but the focus of this blog post is on engineering and the actual execution of the sunset.
Process: Pre-code deletion
Use Feature Flags and Turn off Traffic
Once the communication had been done through emails, in-product announcements, and posts in the user forums, we started focusing on the execution. Prior to the day of each sunset, we used our feature flagging infrastructure to build a switch to disable access to the interface for Wholesale and Manufacturing. Feature flags are an integral part of the continuous deployment process at Etsy. Feature flags reinforce the benefits of small changes and continuous delivery.
On the day of the sunset, all we had to do was deploy a one line configuration change and the product was shut off since there was a feature flag that controlled access to these products.
A softer transition is often preferable to a hard turn off. For example, we disabled the ability for buyers to create new orders one month before shutting Etsy Wholesale off. That gave sellers a chance to service the orders that remained on-platform, avoiding a mad-dash at the end.
Export Data for Users
Once the Etsy Wholesale platform was turned off, we created data export files for each seller and buyer with information about every order they received or placed during the five years that the platform was active. Generating and storing these files in one shot allowed us to clean up the wholesale codebase without fear that parts of it would be needed later for exporting data.
Set Up Redirects
We highly recommend redirects through feature flags, but a hard DNS redirect might be required in some circumstances. The sunset of Etsy Studio was complicated by the fact that in the middle of this project, etsy.com was being migrated from on-premise hosting to the cloud. To reduce complexity and risk for the massive cloud migration project, Etsy Studio had to be shut off before the migration began. On the day before the cloud migration, a DNS redirect was made to forward any request on etsystudio.com to a special page on etsy.com that explained that Etsy Studio was being shut down. Once the DNS change went live, it effectively shut off Etsy Studio completely.
Code Deletion Methodology:
Once we confirmed that all three products were no longer receiving traffic, we kicked off the toughest part of the engineering process: deleting all the code. We tried to phase it in two parts, as tightly and loosely integrated products. Integrations in the most sensitive/dangerous spots were prioritized, and safer deletions were done later as we were heading into the holiday season (our busiest time of the year).
For Etsy Wholesale and Etsy Manufacturing, we had to remove the code piece-by-piece because it was tightly integrated with other features on the site. For Etsy Studio, we thought we would be able to delete the code in one massive commit. One benefit of our continuous integration system is that we can try things out, fail, and revert without negatively affecting our users. This proved valuable as when we tried deleting the code one massive commit, some unit tests for the Etsy codebase started failing. We realized that small dependencies between the code had formed over time. We decided to delete the code in smaller, easier to test, chunks.
a small example of dependencies creeping in where you least expect them.
Challenges: Planning (or lack of it) for slowdowns
During the process of sunsetting,we didn’t consider how busy other teams would be heading into the holiday season. This slowed down the process of getting code reviews approved. This became especially crucial for us since we were removing and modifying big chunks of code maintained by other teams.
There were also several other big projects in flight while we were trying to delete code across our code base and that slowed us down. One example that I already mentioned was cloud migration: we couldn’t shut off Etsy Studio using a config flag and we had to work around it.
Commit Size and Deploys
To reduce risk,our intention was to keep our commits small, but when trying to delete so much code at once, it’s hard to keep all your commits small. Testing and deploying was a least 50% of our team’s time. Our team made about 413 commits over five months, deleting 275,000 lines of code. That averages out to 630 lines of code deleted per commit, which were frequently deployed one at a time.
We actively think of compliance when building new things, but it is also important to keep in mind compliance requirements when you delete code. Etsy’s SOX compliance system requires that certain files in our codebase are subject to extra controls. When we deploy changes to such files, we need additional reviews and signoffs. We had to do 44 SOX reviews since we did multiple small commits. Each review requires approvals by multiple people and this added on average a few hours to each bit of deletion we did. Similarly, we considered user privacy and data protection in how to make retention decisions about sunsetted products, how to make data available for export, and how it impacts our terms and policies.
Deleting so much code can be a difficult process. We had to revert changes from production at least five times, which, for the most part was simple. One of these five reverts was complicated by a data corruption issue affecting a small population of sellers, which required several days of work to write, test, and run a script to fix the problem.
We measured success using the following metrics:
Code Deletion: 275,000
Test Coverage: We caused a slight drop in test coverage metrics because the Etsy Studio project was well above average, while Etsy Wholesale and Etsy Manufacturing were just slightly below average.
System Complexity: Across 8+ Etsy systems: listing management, listing page, payments, search indexes, authentication, member conversations, analytics, member services and our global header user interface,
Operational hours: Saved 152 member support hours a month and about 320 engineering hours a month
From 1000s of error logs a day for wholesale, to less than 100 (eventually we got this to zero)
The roots that three products had in our systems demonstrated the challenges in building and maintaining a standalone product alongside our core marketplace. The many branching pieces of logic that snuck in made it difficult to reuse lots of existing code. By deleting 275,000 lines of code, we were able to reduce tech debt and remove roadblocks for other engineers.
We recently published our company’s Guiding Principles. These are five common guideposts that apply to all organizations and departments within Etsy. We spent a great deal of time discussing, brainstorming, and editing these. By one estimate, over 30% of the company had some input at some phase of the process. This was a lot of effort by a lot of people but this was important work. These principles need to not only reflect how we currently act but at the same time they need to be aspirational for how we want to behave. These principles will be used in performance assessments, competency matrices, interview rubrics, career discussions, and in everyday meetings to refocus discussions.
One of the five principles is focused on diversity and inclusion. The principle states:
We embrace differences.
Diverse teams are stronger, and inclusive cultures are more resilient. When we seek out different perspectives, we make better decisions and build better products.
Why would we include diversity and inclusion as one of our top five guiding principles? One reason is that Etsy’s mission is to Keep Commerce Human. Etsy is a very mission-driven company. Many of our employees joined and remain with us because they feel so passionate about the mission. Every day, we keep commerce human by helping creative entrepreneurs find buyers who become committed fans of the seller’s art, crafts, and collections. The sellers themselves are a diverse group of individuals from almost every country in the world. We would have a hard time coming to work if the way we work, the way we develop products, the way we provide support, etc. isn’t done in a manner that supports this mission. Failing to be diverse and inclusive would fail that mission.
Besides aligning with our mission, there are other reasons that we want to have diverse teams. Complicated systems, which feature unpredictable, surprising, and unexpected behaviors have always existed. Complex systems, however, have gone from something found mainly in large systems, such as cities, to almost everything we interact with today. Complex systems are far more difficult to manage than merely complicated ones as subsystems interact in unexpected ways making it harder to predict what will happen. Our engineers deal with complex systems on a daily basis. Complexity is a bit of an overloaded term, but scholarly literature generally categorizes it into three major groups, determined according to the point of view of the observer: behavioral, structural, and constructive.1 Between the website, mobile apps, and systems that support development, our engineers interact with highly complex systems from all three perspectives every day. Research has consistently shown that diverse teams are better able to manage complex systems.2
We recently invited Chris Clearfield and András Tilcsik, the authors of Meltdown (Penguin Canada, 2018), to speak with our engineering teams. The book and their talk contained many interesting topics, most based on Charles Perrow’s book, Normal Accident Theory (Princeton University Press; revised ed. 1999). However, perhaps the most important topic was based on a series of studies performed by Evan Apfelbaum and his colleagues at MIT. This study revealed that as much as we’re predisposed to agree with a group, our willingness to disagree increases dramatically if the group is diverse.3 According to Clearfield and Tilcsik, homogeneity may facilitate “smooth, effortless interactions,” but diversity drives better decisions. Interestingly, it’s the diversity and not necessarily the specific contributions of the individuals themselves, that causes greater skepticism, more open and active dialogue, and less group-think. This healthy skepticism is incredibly useful in a myriad of situations. One such situation is during pre-mortems, where a project team imagines that a project has failed and works to identify what potentially could lead to such an outcome. This is very different from a postmortem where the failure has already occurred and the team is dissecting the failure. Often individuals who have been working on projects for weeks or more are biased with overconfidence and the planning fallacy. This exercise can help ameliorate these biases and especially when diverse team members participate. We firmly believe that when we seek out different perspectives, we make better decisions, build better products, and manage complex systems better.
Etsy Engineering is also incredibly innovative. One measure of that is the number of open source projects on our GitHub page and the continuing flow of contributions from our engineers in the open source community. We are of course big fans of open source as Etsy, like most modern platforms, wouldn’t exist in its current form without the myriad of people who have solved a problem and published their code under an open source license. But we also view this responsibility to give back as part of our culture. Part of everyone’s job at Etsy is making others better. It has at times been referred to as “generosity of spirit”, which to engineers means that we should be mentoring, teaching, contributing, speaking, writing, etc.
Another measure of our innovation is our experiment velocity. We often run dozens of simultaneous experiments in order to improve the buyer and seller experiences. Under the mission of keeping commerce human, we strive every day to develop and improve products that enable 37M buyers to search and browse through 50M+ items to find just the right, special piece. As you can imagine, this takes some seriously advanced technologies to work effectively at this scale. And, to get that correct we need to experiment rapidly to see what works and what doesn’t. Fueling this innovation is the diversity of our workforce.
Companies with increased diversity unlock innovation by creating an environment where ideas are heard and employees can find senior-level sponsorship for compelling ideas. Leaders are twice as likely to unleash value-driving insights if they give diverse voices equal opportunity.4
So diversity fits our mission, helps manage complex systems, and drives greater innovation, but how is Etsy doing with respect to diversity? More than 50% of our Executive Team and half of our Board of Directors are women. More than 30% of Etsy Engineers identify as women/non-binary and more than 30% are people of color.5 These numbers are industry-leading, especially when compared to othertech companies who report “tech roles” and not the more narrow category, “engineering” roles. Even though we’re proud of our progress, we’re not fully satisfied. In October 2017, we announced a diversity impact goal to “meaningfully increase representation of underrepresented groups and ensure equity in Etsy’s workforce.” To advance our goal, we are focused on recruiting, hiring, retention, employee development, mentorship, sponsorship, and building an inclusive culture.
We have been working diligently on our recruiting and hiring processes. We’ve rewritten job descriptions, replaced some manual steps in the process with third-party vendors, and changed the order of steps in the interview process, all in an effort to recruit and hire the very best engineers without bias. We have also allocated funding and people in order to sponsor and attend conferences focused on underrepresented groups in tech. We’ll share our 2018 progress in Q1 2019.
Once engineers are onboard, we want them to bring their whole selves to work in an inclusive environment that allows them to thrive and be their best. One thing that we do to help with this is to promote and partner directly with employee resource groups (ERGs). Our ERGs include Asian Resource Community, Black Resource and Identity Group at Etsy, Jewish People at Etsy, Hispanic Latinx Network, Parents ERG, Queer@Etsy, and Women and NonBinary People in Tech. If you’re not familiar with ERGs, their mission and goals are to create a positive and inclusive workplace culture where employees from underrepresented backgrounds, lifestyles, and abilities have access to programs that foster a sense of community, contribute to professional development, and amplify diverse voices within our organization. Each of these ERGs has an executive sponsor. This ensures that there is a communication channel with upper management. It also highlights the value that we place upon the support that these groups provide.
We are also focused on retaining our engineers. One of the things that we do to help in this area is to monitor for discrepancies that might indicate bias. During our compensation, assessment, and promotion cycles, we evaluate for inconsistencies. We perform this analysis both internally and through the use of third parties.
Etsy Engineering has been a leader and innovator in the broader tech industry with regard to technology and process. We also want to be leaders in the industry with regards to diversity and inclusion. It is not only the right thing to do but it’s the right thing to do for our business. If this sounds exciting to you, we’d love to talk, just click here to learn more.
1 Wade, J., & Heydari, B. (2014). Complexity: Definition and reduction techniques. In Proceedings of the Poster Workshop at the 2014 Complex Systems Design & Management International Conference. 2 Sargut, G., & McGrath, R. G. (2011). Learning to live with complexity. Harvard Business Review, 89(9), 68–76 3 Apfelbaum EP, Phillips KW, Richeson JA (2014) Rethinking the baseline in diversity research: Should we be explaining the effects of homogeneity? Perspect Psychol Sci 9(3):235–244. 4 Hewlett, S. A., Marshall, M., & Sherbin, L. (2013). How diversity can drive innovation. Harvard Business Review. 5 Etsy Impact Update (August 2018). https://extfiles.etsy.com/Impact/2017EtsyImpactUpdate.pdf