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.”

SAP forms the critical backbone of thousands of enterprises, supporting critical business functions such as finance, supply chain, warehouse management, and more. Google Cloud provides a highly scalable and resilient infrastructure to run such workloads and offers tools, such as Smart Analytics and Machine Learning that can accelerate your organization’s digital transformation. 

In fact, a recent study by Forrester found that running SAP on Google Cloud can generate a 160% return on investment and a payback period of six months or less, thanks to legacy infrastructure cost savings, downtime avoidance, and productivity improvements.

How you deploy your SAP systems across your network has a tremendous impact on its availability, resilience, and performance. In addition to separate production and high-availability (HA) environments, SAP deployments typically include sandbox, development, quality assurance (QA), and disaster recovery environments as well. 

Because most of the Google network is virtual, SAP administrators can easily design complex landscapes that suit your organization’s SAP deployment and organizational structure while also meeting security and operational requirements. 

As you get started with SAP on Google Cloud, you’ll need to decide how to configure your networking to ensure the availability and performance of various SAP systems. Here’s a look at your options.

VPC and shared VPC

A virtual private cloud (VPC) is a secure, isolated private network hosted within Google Cloud. VPCs are global in Google Cloud, so a single VPC can span multiple regions without communicating across the public internet. Similarly, subnets can span across zones within a region. A zone represents a single failure domain, so typical SAP deployments place production and HA systems in different zones to ensure resiliency. Google Cloud simplifies this type of deployment, because subnets containing both production and HA systems can span multiple zones.  

This capability also simplifies SAP clustering, since the cluster’s virtual IP (VIP) address can be in the same range as those of the production and HA machines. This configuration shields the floating IP using Google internal load balancers and is applicable to HA clustering of the application layer (ASCS and ERS) and the HANA database layer (HANA Primary and Secondary).

Shared VPCs are a feature unique to Google Cloud that allows an organization to connect resources from multiple projects to a common VPC network. This lets them communicate with each other securely and efficiently using internal IPs. You can also centrally control the network for all SAP projects (service) from the Host project while using firewalls to inspect communication between compute engines in the same subnet, and between those in different subnets. (Best practice is to limit the communication between these systems to only the required ports — typically via SAP remote function call (RFC) communication at Layer 4.)

When designing your network, start with a host project containing one or more Shared VPC networks. You can attach additional service projects to a host project, which allows them to participate in the Shared VPC. It’s common practice to have multiple service projects operated and administered by various departments or teams in your organization.

Depending on your needs, you can deploy SAP on a single Shared VPC or multiple ones. The two scenarios differ in terms of network control, SAP environment isolation, and network inspection. Let’s look more closely at these differences.

Scenario 1: Deploying SAP on a single Shared VPC

If you require only a single network inspection, deploying SAP on a single Shared VPC has the advantage of simplicity and reduces administrative overhead.

• Network control: The Shared VPC serves as the network hub, allowing central network management based on identity access management (IAM) roles for the network team(s) in both production and non-production environments.
• SAP environment isolation: You can create projects and subnets for each SAP environment. Projects help group resources together for finer IAM control and billing visibility, while subnets provide network isolation for individual SAP environments. In service projects, compute engines can communicate by default; however, you can adopt simple firewall rules to block communication between compute engines within a subnet or in separate subnets.
• Network inspection: Use Google Cloud firewalls to allow only the required ports for communication between SAP systems. Leverage network tags and service accounts to define granular control for both north-south and east-west traffic.

Scenario 2: Multiple Shared VPCs for SAP deployment

In scenarios requiring additional network inspections, you can create multiple Shared VPCs, typically one per environment. Use peering between these Shared VPCs to enable RFC communication among the SAP development, QA, and production systems.

• Network isolation: Multiple Shared VPCs are completely isolated from each other except via specific ports opened in Google Cloud firewalls. This allows additional East-West traffic inspection by a Network Virtual Appliance (NVA) within a Google Cloud network. 
• Network control:As the number of Shared VPCs increases, activities such as peering and firewall policies also increase. This diminishes the central network control that Shared VPCs offer, so the network team should plan to manage the policies in each VPC separately.

Hybrid scenarios – for example, one Shared VPC for the production environment and one Shared VPC for all non-production systems — are also possible. This arrangement allows network inspection between production and non-production systems, and limits the number of central network administration layers to two.

Configuring the networking environment for multiple SAP systems can be a complex process. Thanks to Google Cloud’s Shared Virtual Clouds and other tools, SAP administrators can create scalable, secure networks that provide logic, resilience, and visibility to their cloud deployments.Learn more about these networking capabilities and our full offerings for SAP customers.

Over the past few years, many organizations have experienced the benefits of migrating their SAP solutions to Google Cloud. But this migration can do more than reduce IT maintenance costs and make data more secure. By leveraging BigQuery, SAP customers can complement their SAP investments and gain fresh insights by consolidating enterprise data and easily extending it with powerful datasets and machine learning from Google. 

BigQuery is a leading cloud data warehouse, fully managed and serverless, and allows for massive scale, supporting petabyte-scale queries at super-fast speeds. It can easily combine SAP data with additional data sources, such as Google Analytics or Salesforce, and its built-in machine learning lets users operationalize machine learning models using standard SQL — all at a comparatively low cost. 

If your SAP-powered organization is looking to supercharge its analytics with the strength of BigQuery, read on for considerations and recommendations for modeling with SAP data. These guidelines are based on our real-world implementation experience with customers and can serve as a roadmap to the analytics capabilities your business needs.

Considerations for data replication 

Like most technology journeys, this one should start with a business objective. Keeping your intended business value and goals in mind is critical to making the right decisions in the early steps of the design process.

When it comes to replicating the data from an SAP system into BigQuery, there are multiple ways to do it successfully. Decide which method will work best for your organization by answering these questions:

• Does your business need real-time data? Will you need to time travel into past data?
• Which external datasets will you need to join with the replicated data?
• Are the source structures or business logic likely to change? Will you be migrating the SAP source systems any time soon? For instance, will you be moving from SAP ECC to SAP S/4HANA?

You’ll also need to determine whether replication should be done on a table-by-table basis or whether your team can source from pre-built logic. This decision, along with other considerations such as licensing, will influence which replication tool you should use.

Replicating on a table-by-table basis
Replicating tables, especially standard tables in their raw form, allows sources to be reused and ensures more stability of the source structure and functional output. For example, the SAP table for sales order headers (VBAK) is very unlikely to change its structure across different versions of SAP, and the logic that writes to it is also unlikely to change in a way that affects a replicated table. 

Something else to consider: Reconciliation between the source system and the landing table in BigQuery is linear when comparing raw tables, which helps avoid issues in consolidation exercises during critical business processes, such as period-end closing. Since replicated tables aren’t aggregated or subject to process-specific data transformation, the same replicated columns can be reused in different BigQuery views. You can, for instance, replicate the MARA table (the material master) once and use it in as many models as needed. 

Replicating pre-built logic
If you replicate pre-built models, such as those from SAP extractors or CDS views, you don’t need to build the logic in BigQuery, since you’re using existing logic. Some of these extraction objects have embedded delta mechanisms, which may complement a replication tool that can’t handle deltas. This will save initial development time, but it can also lead to challenges if you create new columns, or if customizations or upgrades change the logic behind the extraction. 

It’s also important to note that different extraction processes may transform and load the same source columns multiple times, which creates redundancy in BigQuery and can lead to higher maintenance needs and costs. However, replicating pre-built models may still be a good choice, since doing so can be especially useful for logic that tends to be immutable, such as flattening a hierarchy, or logic that is highly complex.

How you approach replication will also depend on your long-term plans and other key factors — for example, the availability (and curiosity) of your developers, and the time or effort they can put into applying their SQL knowledge to a new data warehouse. 

With either replication approach, bear in mind when designing your replication process that BigQuery is meant to be an append-always database — so post-processing of data and changes will be required in both cases. 

Processing data changes

The replication tool you choose will also determine how data changes are captured (known as CDC – change data capture). If the replication tool allows for it (for example as SAP SLT does) the same patterns described in the CDC with BigQuery documentation also apply to SAP data. 

Because some data, like transactions, are known to be less static than others (e.g., master data), you need to decide what should be scanned in real time, what will require immediate consistency, and what can be processed in batches to manage costs. This decision will be based on the reporting needs from the business.

Consider the SAP table BUT000, containing our example master data for business partners, where we have replicated changes from an SAP ERP system:

In an append-always replication in BigQuery, all updates are received as new records. For example, deleting a record in the source will be represented as a new record in BigQuery with a deletion flag. This applies to whether the records are coming from raw tables like BUT000 itself or pre-aggregated data, as from a BW extractor or a CDS view.

Let’s take a closer look at data coming particularly from the partners “LUCIA” and “RIZ”. The operation flag tells us whether the new record in BigQuery is an insert (I), update (U) or deletion (D), while the timestamps help us identify the latest version of our business partner.

If we want to find the latest updated record for the partners LUCIA and RIZ, this is what the query would look like:

  SELECT partner,
        ARRAY_AGG(i1 ORDER BY i1.recordstamp DESC LIMIT 1) AS row
FROM SAP_ECC.but000 i1 
WHERE partner in ('LUCIA','RIZ')
    GROUP BY partner

With the following result:

After identifying stale records for “LUCIA” and “RIZ” business partners, we can proceed to deleting all stale records for “LUCIA” if we do not want to retain the history. In this example, we are using a different table to which the same replication has been done, for the purpose of comparison and to check that all stale records have been deleted for the selection made and that we only kept last updated records. For example:

  DELETE SAP_HANA.but000 i1
WHERE
i1.recordstamp < TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 HOUR) AND
i1.recordstamp < (SELECT MAX(recordstamp) FROM SAP_HANA.but000 i2
WHERE
i1.partner = i2.partner
and partner="LUCIA")

You can also use the following query to retrieve stale records for “LUCIA” partner before moving forward with deletion

  SELECT partner, operation_flag, recordstamp  FROM SAP_HANA.but000 i1
WHERE
i1.recordstamp < TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 HOUR) 
AND
i1.recordstamp < (SELECT MAX(recordstamp) FROM SAP_HANA.but000 i2 
WHERE 
i1.partner = i2.partner
and partner="LUCIA")

Which produces all of the records, except the latest update:

Partitioning and clustering

To limit the number of records scanned in a query, save on cost and achieve the best performance possible, you’ll need to take two important steps: determine partitions and create clusters. 

Partitioning
A partitioned table is one that’s divided into segments, called partitions, which make it easier to manage and query your data. Dividing a large table into smaller partitions improves query performance and controls costs because it reduces the number of bytes read by a query.

You can partition BigQuery tables by:

• Time-unit column: Tables are partitioned based on a “timestamp,” “date,” or “datetime” column in the table.
• Ingestion time: Tables are partitioned based on the timestamp recorded when BigQuery ingested the data.
• Integer range: Tables are partitioned based on an integer column.

Partitions are enabled when the table is created, as in the example below.  A great tip is to always include the partition filter as shown on the left-hand side of the query.

Clustering
Clustering can be created on top of partitioned tables by applying the fields that are likely to be used for filtering. When you create a clustered table in BigQuery, the table data is automatically organized based on the contents of one or more of the columns in the table’s schema. The columns you specify are then used to colocate related data.

Clustering can improve the performance of certain query types — for example, queries that use filter clauses or that aggregate data. It makes a lot of sense to use them for large tables such as ACDOCA, the table for accounting documents in SAP S/4HANA. In this case, the timestamp could be used for partitioning, and common filtering fields such as the ledger, company code, and fiscal year could be used to define the clusters.

A great feature is that BigQuery will also periodically recluster the data automatically.

Materialized views

In BigQuery, materialized views are precomputed views that periodically cache the results of a query for better performance and efficiency. BigQuery uses precomputed results from materialized views and, whenever possible, reads only the delta changes from the base table to compute up-to-date results quickly. Materialized views can be queried directly or can be used by the BigQuery optimizer to process queries to the base table.

Queries that use materialized views are generally completed faster and consume fewer resources than queries that retrieve the same data only from the base table. If workload performance is an issue, materialized views can significantly improve the performance of workloads that have common and repeated queries. While materialized views currently only support single tables, they are very useful common and frequent aggregations like stock levels or order fulfillment.

Further tips on performance optimization while creating select statements can be found in the documentation for optimizing query computation.

Deployment pipeline and security

For most of the work you’ll do in BigQuery, you’ll normally have at least two delivery pipelines running — one for the actual objects in BigQuery and the other to keep the data staging, transforming, and updated as intended within the change-data-capture flows. Note that you can use most existing tools for your Continuous Integration / Continuous Deployment (CI/CD) pipeline — one of the benefits of using an open system like BigQuery. But, if your organization is new to CI/CD pipelines, this is a great opportunity to gradually gain experience. A good place to start is to read our guide for setting up a CI/CD pipeline for your data-processing workflow.  

When it comes to access and security, most end-users will only have access to the final version of the BigQuery views. While row and column-level security can be applied, as in the SAP source system, separation of concerns can be taken to the next level by splitting your data across different Google Cloud projects and BigQuery datasets. While it’s easy to replicate data and structures across your datasets, it’s a good idea to define the requirements and naming conventions early in the design process so you set it up properly from the start. 

Start driving faster and more insightful analytics

The best piece of advice we can give you is this: Try it yourself. Anyone with SQL knowledge can get started using the free BigQuery tier. New customers get $300 in free credits to spend on Google Cloud during the first 90 days. All customers get 10 GB storage and up to 1 TB queries/month, completely free of charge. In addition to discovering the massive processing capabilities, embedded machine learning, multiple integration tools, and cost benefits, you’ll soon discover how BigQuery can simplify your analytics tasks. 

If you need additional assistance, our Google Cloud Professional Services Organization (PSO) and Customer Engineers will be happy to help show you the best path forward for your organization. For anything else, contact us at cloud.google.com/contact.

Patients about to undergo a healthcare procedure understandably want the best medical professionals they can get. But how can they know which doctors have had the most experience and the best outcomes with that particular procedure? How can they make an informed decision about which doctor to select when the information they have is limited to the doctor’s practice area and subjective reviews from other patients?

MD Insider is working to solve that problem using machine learning (ML) to objectively analyze doctor performance. By analyzing data from thousands of institutions and millions of doctor-patient interactions and medical events, MD Insider identifies physician performance insights based on their experience and outcomes. Insights are then integrated into a triage engine, that enables consumers to search for and schedule appointments with providers who meet their clinical criteria and convenience preferences, such as insurances accepted, office hours, locations, and language.

MD Insider also offers robust data APIs to help health systems, health plans, and employers reduce costs and improve quality of care. Payers use the APIs to curate high-quality provider networks and manage provider directories. Examples of MD Insider’s data APIs include Provider Experience and Share of Practice metrics, Provider Quality and Outcomes, Network Modeling, Expert Clinical Search Taxonomy, Find a Provider, Acute-Care Hospital Quality, and Provider and Facility Metadata.

“We use Google Cloud Platform the way the cloud was supposed to be used. By comparison, other cloud providers feel like you’re renting somebody else’s data center.”

—Ed Holsinger, Lead Data Engineer and Head of Data Science, MD Insider

MD Insider is continuously ingesting the latest performance data about physicians and analyzing billions of rows of data. Requiring constant scalability, the company was born in the cloud; however, it had difficulty configuring server instances for the optimal balance of memory and CPU, and its Hadoop cluster had to be kept running 24/7. Network performance was often slow for no apparent reason. As a result, failure rates from node timeouts increased, and costs grew along with the data. MD Insider had to estimate its usage and pay up front, and received little financial benefit from sustained use commitments.

Knowing that data would continue to grow, MD Insider decided to move its data services — the most demanding and complex portion of its infrastructure — to Google Cloud Platform (GCP), and took advantage of GCP managed services for container management and big data analytics.

“One of the reasons we decided to move to Google Cloud Platform is because it feels like a unified, well-designed cloud architecture and pricing model,” says Ed Holsinger, Lead Data Engineer and Head of Data Science at MD Insider. “We use Google Cloud Platform the way the cloud was supposed to be used. By comparison, other cloud providers feel like you’re renting somebody else’s data center.”

“Moving to Google Cloud Platform and using Kubernetes Engine gave us 5x the processing power for analyzing physician performance at 75% less cost. Our data scientists have more power than ever before to generate insights for our customers.”

—Ed Holsinger, Lead Data Engineer and Head of Data Science, MD Insider

5x the performance, 75% less cost

MD Insider now uses Kubernetes Engine to automate container management and deploy clusters in minutes with just a few clicks. When hundreds of machines are required to analyze a large dataset, automation in Kubernetes Engine deploys ML models as containers, each of which manages the full lifecycle of its task, including scaling up resources, deploying results, and scaling back down when the task is finished. It’s easy for MD Insider to specify exactly how much CPU and memory each container needs, helping maximize performance while reducing costs.

“Moving to Google Cloud Platform and Kubernetes Engine gave us 5x the processing power for analyzing physician performance at 75% less cost,” says Ed. “Our data scientists have more power than ever before to generate insights for our customers. Data scoring jobs that used to take three business days now take four hours.”

Adds Galen Meurer, Senior Software Engineer at MD Insider: “Even if all Google Cloud Platform had to offer was Kubernetes Engine, I would still want to use it. Previously we spent up to 30% of our time managing our container infrastructure, which we can now use for product development.”

A foundation for data science

MD Insider was happy to find that GCP offers a wide variety of managed services. For example, the company is supplementing its Kubernetes Engine clusters with BigQuery for its big data masters and selection jobs, enabling scientists to analyze new and different types of data as well as analyze larger datasets in less time. MD Insider also uses Cloud Storage for big data staging and Cloud Dataproc to run managed Apache Spark clusters for data processing.

“Google Cloud Platform gives us an incredibly powerful cloud architecture for data engineering and data science,” says Eric Wilson, CEO of MD Insider. “That gives our scientists independence, they can do what they need to do without waiting and with no contention between them.”

A developer-friendly platform

Migrating its data services was such a success that MD Insider decided to move the rest of its infrastructure to GCP, including the front end for its web application. Since the migration, MD Insider has experienced no unplanned downtime on GCP, allowing it to easily meet the 99.5% uptime SLA it promises to customers. It’s also taking advantage of Build Triggers in Kubernetes Engine to automate container builds and reduce build times by more than 40%. Production code can be updated in seconds, with no impact to end users other than making new features available.

“GCP has simplified our workflow in so many ways, from intelligent load balancing to content delivery and automating builds,” says Matthew Frey, Software Engineer. “Everything on GCP is cohesive and developer friendly, with a superior UI and better network performance than other cloud providers.”

Ryan Beaini, Senior Software Engineer at MD Insider, agrees: “Since we moved to GCP, our developers are definitely happier. The pain and the headaches we experienced because of the limitations of our previous toolset all went away.”

“We’re a small company, but what we’re doing is incredibly important. We’re helping people make decisions about healthcare providers that could impact their lives and even be life-saving. Google Cloud Platform is helping us make our mission bigger, better, and brighter.”

—Eric Wilson, CEO, MD Insider

Securing billions of rows of clinical and non-clinical healthcare data

As a healthcare technology company, MD Insider processes billions of rows of clinical and non-clinical healthcare data. To control user access to GCP, it uses Identity & Access Management (IAM) along with Yubico YubiKeys for hardware-based two-factor authentication when logging into Google Workspace. MD Insider takes comfort that GCP encrypts data at rest by default, and encrypts and authenticates data in transit when data moves outside physical boundaries not controlled by Google or on behalf of Google.

“On GCP, everything that we need to be encrypted for compliance purposes is encrypted, which is fantastic,” says Eric. “When I tell our potential clients and partners about the resources that Google has dedicated to security, it gives them the confidence that their data will be protected.”

Transforming how teams work

As a growing company, MD Insider must collaborate seamlessly between offices in California, Colorado, and Illinois. It relies on Google Workspace for communication and productivity, using Docs, Sheets, and Slides to drive the business. Employee and team files are stored in Drive, and meetings are conducted via Google Meet with Chromebox for Meetings videoconferencing hardware kits. Google Workspace also helps MD Insider maintain information security by authenticating email domains with digital signatures in Gmail and scanning outgoing email using Gmail Data Loss Prevention (DLP).

“I use Google Workspace every day, and everyone else here does too,” says Eric. “Team Drives are a big time saver for us. We’ve let our previous office software expire, because there’s no need to pay for those licenses anymore.”

Promoting healthcare transparency

With GCP helping MD Insider increase velocity and momentum, the company is making exciting progress. For example, it has entered into a strategic partnership with Zelis Healthcare, which will use MD Insider’s API to provide insights for a next-gen analytics platform that will give health plans unprecedented transparency around physician performance.

“We’re a small company, but what we’re doing is incredibly important,” says Eric. “We’re helping people make decisions about healthcare providers that could impact their lives and even be life-saving. Google Cloud Platform is helping us make our mission bigger, better, and brighter.”

*Google Workspace was formerly known as G Suite prior to Oct. 6, 2020.