Anyone who has ever coached or played on a sports team, or had a child involved in sports, knows how difficult scheduling and logistics can be. From game and practice schedules, to uniforms and who’s bringing the snacks, it can be a lot for coaches, administrators, parents, and players to manage.

It’s no wonder that TeamSnap, a sports team, club, and tournament management app, has exploded in popularity worldwide. By syncing events to everyone’s personal calendars and providing messaging and payment tracking, TeamSnap makes communication and organization easy.

TeamSnap markets its app to coaches, players, and clubs via targeted YouTube ads. It also uses Google AdWords and DoubleClick to advertise on search results and run programmatic campaigns. These methods have been highly effective, helping TeamSnap grow to millions of users worldwide and become one of the most popular apps in the iOS app store.

As its business and data grew, TeamSnap was challenged to track ROI and measure the customer journey across channels and devices over time. The company’s marketing budget grew quickly, making it even more important to spend wisely. With data in Google Analytics 360, DoubleClick Campaign Manager, Google AdWords, and Salesforce, TeamSnap needed a way to link and correlate those data sources in a scalable, timely, and cost-effective way to understand the true impact of its digital marketing across websites and mobile apps.

To avoid the painstaking manual process of pulling data from multiple sources, TeamSnap began using Google Analytics 360, which integrates with Google BigQuery, to provide a fully managed big data analysis service. TeamSnap analyzes the data using Tableau, which connects directly to Google BigQuery for fast analytics and helps the company share and collaborate on that information with self-service ease.

The combination allows TeamSnap to easily track the activity of millions of users with self-service ease, without worrying about the scalability or availability of the big data platform.

“Before Google Analytics 360, Google BigQuery, and Tableau, tracking our return on ad spend was difficult because we had so much data,” says Ken McDonald, Chief Growth Officer at TeamSnap. “We didn’t always have insights to make the best choices. We don’t have that problem anymore because we’ve moved to real-time reporting. We find additional revenue growth opportunities almost daily.”

Making Ad Dollars Work Harder

TeamSnap now automatically imports unsampled Google Analytics 360 logs into the Google BigQuery data warehouse. To import data from other sources such as Google AdWords, DoubleClick, and YouTube, TeamSnap uses Google BigQuery Data Transfer Service. With all relevant data consolidated in Google BigQuery, TeamSnap can use Tableau to perform advanced analytics on its digital marketing, executing ad-hoc analyses in seconds, while eliminating data sampling issues, to improve accuracy. These analyses can also be reused and shared with internal and external stakeholders via Tableau Online, promoting governed reuse and consistency.

“Using Google Analytics 360 and Google BigQuery with Tableau to track our return on ad spend is ideal,” says Ken. “It’s easy to use SQL to query the data or explore it with drag-and-drop ease.”

With Google BigQuery, Ken and his team can bring all the data from the TeamSnap billing systems, internal CRM, and other Google services into one straightforward dataset that everyone uses. With Tableau, users are able to perform self-service analytics on this data and provision analyses via shared dashboards that communicate the same consistent truth across the company. These dashboards provide a single view of the business to discover new patterns and questions worth analyzing.

All of this results in enormous time savings because no one is re-inventing the wheel. “Using these tools, we immediately reallocated $300,000 of ad spend that was performing poorly, generating 200% ROI in the first two days,” says Ken.

Ken now spends his time analyzing data instead of trying to pull it all together, identifying pockets of inefficient spend in real time and reallocating those marketing dollars toward better performing campaigns.

“Before, we could only focus on the largest campaign-level datasets because it was so time consuming to pull the data,” he says. “With Google BigQuery and Tableau, we can examine our advertising ROI much more granularly and reallocate more than $10 million in ad spend annually to grow the company faster and more efficiently.”

More Effective A/B Testing

To make sure it is delivering the best customer experiences, TeamSnap uses Google Optimize to run A/B tests on its website. It uses Google BigQuery and Tableau to verify and supplement these findings by measuring longer-term customer behavior across devices, spanning both web and mobile apps.

By pulling in data from Google Optimize, Google Analytics 360, Salesforce, and in-house billing and CRM systems, and understanding it with Tableau, TeamSnap has increased the accuracy and effectiveness of its A/B testing, gaining a more complete picture of customer onboarding and activity. In some cases, it found that short-term indicators it previously trusted were actually poor predictors of long-term behavior.

“Integration between Google Analytics 360 and Google BigQuery is seamless, giving us much more confidence in our A/B testing,” says Ken. “We’re constantly finding new and interesting ways to use our digital marketing data. Often, making a simple change can increase revenue by hundreds of thousands of dollars a year.”

Improving Product Quality

TeamSnap also uses Google BigQuery and Tableau to improve its own product, tracking customer activity at such a granular level that usability and functionality issues can be exposed and addressed faster. It’s also increasing customer engagement by verifying that potential customers are coming in through the right onboarding path—for example, a coach versus a player, or a consumer versus a club or other sports business. Using A/B testing to make sure customers are routed to the appropriate flow, TeamSnap drove $4 million in additional customer value each year.

“We initially chose Google BigQuery and Tableau to help with marketing, but we realized quickly that they could help us on the product side as well,” says Ken. “Most of the testing we do is about making things better and easier for our customers, and we’re accelerating that process with Google BigQuery and Tableau.”

Have you ever heard of an optimization problem? Imagine you have a million marbles, all of different sizes, colors, patterns, and weights. You need to fill up 1,000 jars of different sizes with them, but each jar has restrictions as to which colors, patterns, and how many marbles of each type it can hold. After filling all the jars, you may keep any leftover marbles, so you want to ensure that these are the shiniest ones in the bunch. How do you go about solving this puzzle? There are many possibilities, but what would be the most efficient way to guarantee you’ll reach the best possible outcome every time? 

At HSBC, our Collateral Treasury desk and Collateral Management team have been solving a similar problem, but instead of marbles and jars, we work with around 50,000 assets that can be used as collateral, and 1,000s of collateral accounts.

Our Collateral Treasury Trading desk helps finance our Markets business by providing the required collateral, such as certain debt or equities, to cover its obligations to a client. The collateral could be used by HSBC for its margin requirements, CCPs (Central Counterparty Clearing Houses), or for securities financing transactions. Each obligation can have different eligibility criteria about what assets can be used as collateral for each client. These rules and restrictions revolve around the type of asset allowed or daily liquidity factors.

The process of matching collateral to obligations is known as an allocation, and it can get complicated the more diverse the collateral pool and the more customers you have. It is important to allocate collateral in the most efficient way and, traditionally, this business problem has been managed manually or by a third party against a set of simple rules.

But by collaborating with Google Cloud, we can improve collateral allocation through automation. Even small efficiency gains have the potential to make a significant difference when the amount of collateral inventory managed is tens of billions of dollars. It means the Collateral Treasury desk is much more efficient when managing its own funding costs or regulatory ratios such as the Liquidity Coverage Ratio (a key financial resource measure for banks that ensures sufficient high quality assets are readily available to survive periods of liquidity stress).

Leveraging AI to tackle a complex business problem

Our solution is OPTIC, a HSBC platform utilizing Google Operation Research Tools, or OR-Tools, an open-source optimization library provided by Google AI. Its main goal is to allow the Collateral Treasury desk to automate the collateral allocation process in the most optimal way on any given day. OPTIC’s architecture is based on microservices and provides the ability to handle large volumes of data, for which a scalable and self-managed infrastructure is needed.  OPTIC runs on Google Kubernetes Engine, which provides it with workload rebalancing, auto-scaling capabilities, and high availability. 

Additionally, we collaborated with Google Operations Research, which gave us access to the experience of Google AI engineers who were able to advise us on the best way to implement their optimization libraries to solve our business problem.  

We’ve found that using linear programming solvers such as Google OR-Tools is the best way to achieve the optimization capability that fundamentally changes how we manage our inventory. It enables us to optimize for multiple outcomes and be certain that we are doing this in the most efficient way possible. 

Finding the optimal way forward with automation

OPTIC works by consuming data feeds from a multitude of systems, then it standardizes the data, and combines with decision-making parameters and weightings Google OR-Tools can use, to understand and arrive at an optimal outcome. OPTIC can also provide insights and metrics that help optimize business decisions such as which assets can be added or removed in the future to make collateral allocation even more efficient.

Looking forward, this project makes us optimistic about using Google Kubernetes Engine to manage more of our microservices in other platforms. This will mean that we can scale without worrying about hardware or making big changes to our environment. With this solution, we’ll be able to mobilize and optimize our collateral according to our own view of the value and quality of the collateral, as well as the best fit for our exposures at any given time.  

Over time, the project can bring visible long-term benefits to HSBC’s Markets business, including decreased operational risks and potential to save significant funding costs. Next, we will continue to add new capabilities and data sources to our solution to continue solving some of the most complex business challenges in our industry.

Volkswagen strives to design beautiful, performant, and energy efficient vehicles. This entails an iterative process where designers go through many design drafts, evaluating each, integrating the feedback, and refining.

For example, a vehicle’s drag coefficient—its resistance to air—is one of the most important factors of energy efficiency. Thus, getting estimates of the drag coefficient for several designs helps the designers experiment and converge toward more energy-efficient solutions. The cheaper and faster this feedback loop is, the more it enables the designers.

Unfortunately, estimating drag coefficient is an expensive and time-consuming operation that involves either a physical wind tunnel or a computationally intensive simulation. This can be a bottleneck in the feedback cycle.

For this reason, Volkswagen and Google Cloud decided to collaborate on a joint research project to investigate using machine learning (ML) to get fast and inexpensive estimates of the drag coefficient. In this post, we’ll explore the challenges and approaches undertaken in this project.

The core principles of the project were simple. First, we needed to collect a dataset of existing car designs and their respective drag coefficients. Then, we needed to create a representation of the various cars that would be suitable for ML. The next step was to train a deep learning model to predict the drag coefficient, and then, finally, we would use that model to efficiently estimate drag for any new design.

Representing three-dimensional car designs

Design software recreates a physical object as a three-dimensional triangle mesh made up of three types of objects—faces, edges, and vertices. Figure 1, below, shows such a mesh for an Audi S6. Faces are flat surfaces, such as the window in a car door. An edge is where two faces meet (e.g., the side of the door), and a vertex is where two or more edges meet, such as the corner of the door.

Car bodies, however, come in all shapes and sizes. A Volkswagen Golf economy model is very different from a Tiguan SUV, and a single vehicle can have both large smooth surfaces as well as areas with delicately designed features. Consequently, there can be a huge variety from one polygonal mesh to the next.

ML models need consistent representation in order to form robust generalized rules. With such a dramatic variance between each polygonal mesh, the models would be compromised and the results could have huge margins of error.

We needed to find a way to create simple meshes that capture the shape of the car but are still suited for ML models.

Representing a car with digital shrink wrapping

Rather than building a representation of each car from the ground up, we applied a “shrink wrapping” method for the 3D meshes. The principle is very similar to vacuum-sealing a cucumber. The cucumber is placed in a plastic bag and the air is then gradually removed until the bag fits tightly around it, capturing its shape.

Our approach works similarly: we start with a base mesh, a simple shape that corresponds to the plastic bag, and we deform it until it captures the shape of the target mesh. For our purposes, the base mesh is a simplified representation of a car and the target mesh is the particular car we are designing for at that moment. Such meshes can be defined, managed, and presented to ML models for training using the Tensorflow Graphics and trimesh libraries.

Our “shrink wrapping” method mainly works by iteratively minimizing a measure of distance (e.g., chamfer distance) between the two meshes. Additionally we can regularize our mesh to preserve certain qualities, like smoothness, in the resulting mesh. This iterative optimization is analogous to the vacuum pump, gradually shrinking and fitting the vertices of the mesh as closely as possible to the complex shape of the car. With shrink-wrapping, we are able to produce cleaner meshes that are more suitable to our estimation task. An example of such a procedure is shown in Figure 2.

How to train a model

Shrink-wrapping the 3D car designs was an important first step, but the work was far from over. Our next challenge was to build and test the machine learning algorithms.

We wanted our algorithms to estimate the drag coefficient as accurately and quickly as possible each time it looked at a new design. To do so, we had to train the ML models on existing data.

From publicly available datasets, we calculated the drag coefficients for 800 different car meshes, which we trained the models on. Then, we evaluated the trained models on a further 100 meshes, seeing how accurate their estimates were on new data.

As we worked through this training, we refined our approach. Initially, we tested models based on convolutional neural networks – similar to PointNet – that observed only the vertices, i.e., the fixed points in each mesh. But when we tested mesh-convolutional models – similar to FeastNet – we found a slightly different focus improved the accuracy of the estimates. Rather than focusing on vertices alone, these models looked at a mesh of vertices and how they relate to each other. These models placed each vertex in a richer context, leading to more accurate estimates when air-flow hit particularly subtle design features.

Working in parallel and at scale
To collaborate across time zones and two organizations, we’ve used the Google Cloud Vertex AI platform.

Vertex AI Workbench serves as a central hub to interact with other services and infrastructure on the Vertex AI platform. It enables quick experiments and preparation of training packages for resource-intensive ML model training jobs, all in a Python notebook environment for immediate execution of code. The notebook environments allow code-based interaction with other services on Google Cloud and ML tools such as Vertex AI Training and Vertex AI Pipelines.

The process of training a new model is a seamless one. First, a dataset is prepared and stored in Google Cloud Storage, usually with the help of Tensorflow Datasets. Then, for every ML model we want to test, we package and store the training code as a container image with Google Cloud Build and Container Registry. This ensures that every job is fully documented, including the provided parameters, training code package, logs from the training task, and resulting artifacts such as metrics and model files.

From there, we submit the model to the Vertex AI Training service, which provides easy access to large scale infrastructure and hardware accelerators, such as GPUs and TPUs, by simply defining resource needs when submitting a job. By using Vertex AI Training’s hyperparameter tuning feature, we can run experiments in parallel with multiple neural networks to find the right one for our purposes.

With Vertex AI Tensorboard, we can capture metrics and visualize the results of our experiments. These are readily available to anyone in the team, wherever they are in the world, for a wider discussion.

The first milestone

This joint research effort between Volkswagen and Google has produced promising results with the help of the Vertex AI platform. In this first milestone, the team was able to successfully bring recent AI research results a step closer to practical application for car design. This first iteration of the algorithm can produce a drag coefficient estimate with an average error of just 4%, within a second.

An average error of 4%, while not quite as accurate as a physical wind tunnel test, can be used to narrow a large selection of design candidates to a small shortlist. And given how quickly the estimates appear, we have made a substantial improvement on the existing methods that take days or weeks. With the algorithm that we have developed, designers can run more efficiency tests, submit more candidates, and iterate towards richer, more effective designs in just a small fraction of the time previously required.

Going forward, faster and more accurate estimates could even enable more automated searching for efficient designs, which would help both engineers and designers to hone in on the areas of the vehicle body where they could have the most impact. An important next step will be integrating the results into 3D design software to let designers benefit from the output and provide feedback.

As we continue, our focus is on improving the accuracy of the models. Firstly, we will build a larger, better quality dataset. Secondly, we will improve our shrink-wrapping algorithm to capture more details. Finally, we will enhance our existing models by experimenting with Vertex AI Neural Architecture Search to explore and experiment with different neural architecture options.

Moreover, we believe that our results for drag coefficient estimation is only a starting point for further exploration. There could potentially be numerous use cases in the space of physical simulations and assessments where cost and time savings could be achieved through ML-based estimators.

Acknowledgements

This work wouldn’t have been possible without the contributions from Volkswagen Data:Lab, Google Research, and Google Cloud. Thanks to Ahmed Ayyad, Dr. Andrii Kleshchonok, Dr. Daniel Weimer, Gülce Cesur, Henrik Bohlke, Andreas Müller from Volkswagen, Ameesh Makadia, Ph.D., and Carlos Esteves, Ph.D., from Google Research, and Daniel Holgate, Holger Speh, and Dr. Michael Menzel from Google Cloud.