Learning to use a new database can be daunting, even more so if you don’t already have technical knowledge about databases. In this article, I will break down some database basics, terms you should know, what Firestore is, how it works, how it stores data, and how to get started using it with the assumption that you don’t have any existing database knowledge.

Before we dive into what Cloud Firestore is, let’s discuss some key database terms you should know. Feel free to skip this section if you are already familiar with the basics of Relational and non-relational databases. 

What is a database? 

A database is software that allows you to easily access, manage, modify, update, control and organize data. The way you want to store information can impact what type of database you choose. There are two major categories of databases, Relational and non-relational. 

Relational Database

A relational database can be thought of like a spreadsheet. You can store information in your spreadsheet like this: 

Now, what happens if I want to store information about where Sparrow1 lives, in my spreadsheet, but I don’t care about where the other birds live? I would have to add another column to my spreadsheet, called home, that would only contain data for the sparrow. That would look like this:

Even though I only want to know information about where the sparrow lives, I am required to have blank spaces in the column for all of the other animals. This is because in a relational database, you have a specific structure of your data called a schema. Just like in a spreadsheet, every item you are storing information  on must have a place to put information about the bird’s home, even if you only want that information for one bird. This is enforced by the schema, which is essentially the column headers you put in the sheet and dictates a strict structure for the data, which has pros and cons.

The strict structure of a relational database allows your application to know what kind of data exists, to know what the data type is, and to enforce rules such as requiring data to be unique, or enforcing type of data stored etc. A schema, by design, forces the data in each row to have the same characteristics, which means it is not very flexible, unless you change the schema for the database. That means if you want to add different data that doesn’t fit your existing schema, you have to change the schema. As we discussed above, if you want to change the schema we are using to store information, such as Home, there is some information that will be stored for all rows, even if you don’t want to store anything. The amount of wasted storage is different between database engines, data types etc.  Another thing to consider about Relational databases is that at scale, some traditional Relational databases will require more advanced deployments to handle the scale.

Changing the schema of a relational database can be highly disruptive, especially for busy workloads because it requires running scripts to change the schema and coordinating it carefully with the code changes in the app.  Due to locking, you might even experience downtime in some cases.  Now contrast that with a non-relational document database like Firestore, where you don’t have to worry about schema changes in the databases or downtime as a result of it.

Also, when you have a lot of data that you want to collect and it only applies to a few things in your database, having extra space with no information in it can become wasteful because it uses up storage space in many cases.  A non-relational database can help get around this problem. 

Non-relational databases

Generally speaking, a non-relational database stores information in a different format than a Relational database. There are 4 major categories of non-relational databases that you will hear most frequently.

• Column-Family 
• Document (Firestore) 
• Key-Value 
• Graph 

Since this post is focusing on Firestore, in this section we will dive into what a document database is, how it is used, and when to use it.

Document database (Firestore) 

A document database can be thought of as a multi layered collection of entities, such as this: 

As you can see, when the list is all collapsed, you can only see the information at the top; in this case, that is the BirdID (Cardinal1, Bluejay1, Sparrow1, Cardinal2, Crow1 etc. When I open the list I see “word: word”. For example, the document ID Sparrow1, points to a document with “Type: Sparrow”. I also see “Color: grey”, “Age: 2”, “Gender: f” and “Home: Birdhouse #3”

This is known as a key value pair. For “Type: Sparrow”, Type is the key and Sparrow is the value. All of the keys in the Sparrow1 document are: Type, Color, Age, Gender, House. All of the values in the Sparrow1 document are: Sparrow, grey, 2, f, Birdhouse #3.

Similarly to how the key gives you context, it allows you to ask the computer for a specific piece of information, such as the age of the bird. It is important to decide on a specific key term you will use for each piece of data you collect so your data can be easily read programmatically. This is called an implicit schema, an implied understanding of how data is stored that is not enforced by the database. Let’s go over what happens when we use an implicit schema.

Under Cardinal1, you see Type, Color, Age, and Gender; however, under Sparrow1 you also see House. This is possible because in a non-relational database you don’t have a schema that requires you to store the same information about every bird in your database; instead, you can store the specific information that you need for each bird, regardless of what is stored for other birds. This is a great benefit in terms of flexibility, but because of this flexibility, maintaining standard naming conventions is very important.

Now, let’s discuss why using standard naming conventions is so important. In the example above, if I ask a human: “What is the age of Cardinal1?”, they would probably tell me 2. If I asked them: “What is the Age of Bluejay1?”, they would probably tell me 4. These are both correct answers, but they are only correct because a human is able to assume what Age means. A computer, on the other hand, can’t make assumptions. If I ask a computer: “What is the Age of Cardinal1?” it would say 2, but if I ask it: “What is the Age of Bluejay1?”  it would not know. This is because the computer is looking for the keyword Age and it isn’t able to use any context clues to determine what other words might mean Age. However, if I asked the computer: “What is the BirdAge of Bluejay1?”, the computer would tell me 4. Why do I care that I need to tell the computer to look for BirdAge to get the age of blujay one, but to look for Age to get the age of Cardinal one? I care because it means I would have to write two entirely different sets of instructions (i.e software code) to get the age of Cardinal1 and the age of Bluejay1 if I am not careful in how I structure my data. But when I structure my data well, this is not an issue and is infact a benefit by adding added flexibility. 

What we see from this example, is that even without a strict schema, we can (and should) define conventions for document formats. If conventions aren’t defined, things can get unwieldy quickly. 

How information is accessed

Now, let’s discuss how the information is accessed. If I wanted to know information about which birds are blue in our drop down list example, I would need to expand every section of the list to check if the bird is blue or not. As you can imagine, once you start to get a lot of birds in your database, it becomes cumbersome to open every drop down and see if the bird is blue. Luckily, Firestore lets you run these types of queries against the data  (See more here) and receive all the documents that satisfy your conditions. On the other hand, if I wanted to know all of the information about Cardinal1, I could just open the drop down for Cardinal1 and I would have all of the information about that bird. 

Now let’s start using some Firestore specific terminology. For the example we just discussed:Collections

• In Firestore, your data lives in collections. You can think of collections as tabs in a spreadsheet.
• Collections can be used to organize data. For example, if I decide that I want to collect data about birds and fish, the data about birds could be put in a birds collection, and the data about fish could be put in a Fish collection. ex:

Documents

• This is the unit of storage that Firestore uses. In our example, each bird is its own document. Documents reside in collections. This is what one document would contain:

• Each Document corresponds to a row in the sheet. The following diagram demonstrates that each column header maps to a property name in the document and that each value in a row maps to a value in the document.
• Each document must be identified by a unique identifier. In our example, that is BirdID. Notice that the value for BirdID is stored at the top level of the list, so when the document is closed, you can only see Cardinal1 and Cardinal1 is not also stored within the document.  

References

• All documents can be uniquely identified by their location. Let’s think through this in words first before we move to code. If I want to tell someone to get data about the sparrow from the drop down lists, I would need to tell them:
• In the bird drop down list, can you please get all the information under Sparrow1 and put it on a piece of paper called sparrow1Info?
• Now let’s try that again using Firestore terms. 
• From the birds collection, can you please get the document for sparrow1 from the Firestore database (db) and save it as sparrow1Info?
• Now let’s try it in code.
• var sparrow1Info = db.collection(‘birds’).doc(‘sparrow1’);

Subcollections

• A subcollection is a collection associated with a document. Using our example of the drop down list, we can add a collection called sightings that stores documents about each sighting of the specific bird. This is what that would look like: 

• It is important to note that you don’t need to have the same subcollections on all documents. For example, Cardinal1 can be the only document that has a subcollection of Sightings. 

How to search on Google about Firestore

The hardest part of learning a new technology can often be knowing the right terms to put into Google search to get the answers you are looking for. Here are some key terms that can help you get started

Your question: 

How should I arrange my data to store it in Firestore?

Search:

 Document database implicit schema design

Your Question:

What other databases are similar to firestore?

Search:

What are some document databases 

Your Question:

How do I get all documents in the Birds collection?

Search:

How to use wildcards in Firestore 

What next?

Try this guide to get started building your first application that uses firestore: https://firebase.google.com/docs/firestore/quickstart 

With a data strategy and data warehouse in place, EdTechs are building a data culture that helps everyone – from educators and administrators, to employees in marketing and accounting – make more informed decisions with their data.

So how do you build a data culture in your organization? It starts by asking these questions:

• Are users able to find answers to their data questions from available data?
• Can they act based on available metrics?
• Can they tell a compelling story with the data at hand?

How well is your company using analytics? The matrix  from Looker’s Analytical Maturity eBook, shows ranges from “vanity” (nice to see) metrics to “optimization.” 

Adopting and rolling out your organization’s new data platform

As outlined in the previous blog in this series, From data chaos to data-driven: How dedicated data teams can help EdTechs influence the future of education, a comprehensive data team is essential for building a data warehouse. That data team should include a core education intelligence team. This team can align with analytically savvy members of each department they support. It’s critical that the Education Intelligence team understand each department’s reporting needs and can make adjustments based on user feedback.

Include these key components to ensure smooth adoption for internal teams:

• Share a roadmap: An effective rollout team always knows what’s next on their roadmap and communicates that to the entire organization. Launching analytics across an entire company at once usually leads to slow movement, miscommunication, and lack of adoption. A roadmap will ease this transition.
• Train everyone: This approach makes sure everyone is consistent during the data rollout. Show users how to make the most of the platform your data team has created, and be sure they know where they can go for help.
• Monitor and optimize: Monitor your organization’s analytics usage. Understand which individuals are using your education intelligence system to drive their day-to-day operations. These individuals can provide further insight into what is working. Identifying those who may need more guidance and support ensures they don’t miss out on benefits.

Guild Education: Creating a data culture

Guild Education started working with Google Cloud to build a data culture and implemented Looker as their data platform. 

The company transformed their student success program—in which coaches work directly with connected employees throughout their educational journey—with Looker. “As enrollments increased, even spreadsheets were not able to accurately keep track of caseloads,” Sean McKeever, Senior Business Intelligence Analyst, recalls. “We needed a singular source of truth that could be updated in almost real-time.” In response, they created “Student Rosters” to manage a coach’s student outreach.

Users were thrilled with the new tools, and when the coaching team grew from 20 to 90, Sean created ambassador groups consisting of data specialists to support each department. This sparked Guild Education’s “data-driven evolution.”

“Unexpectedly, the Student Success task force also became an engine for new BI work,” Sean says. “They blew my highest expectations out of the water and started owning virtually the entire process: building requirements, prototyping, testing, and deploying new dashboards and panels—with hardly any help from the BI team.”

These successes have set Guild Education on its way to becoming a fully data-driven company. Unexpectedly, the Student Success task force also became an engine for new BI work…they blew my highest expectations out of the water and started owning virtually the entire process…with hardly any help from the BI team.Sean McKeever
Senior Business Intelligence Analyst, Guild Education

Start your journey from data chaos to data-driven

We hope this three-part series has shown how data analytics has an important role to play in transforming the future of education. EdTech companies are unlocking the power of big data to serve their customers. “The education landscape is changing rapidly, and EdTech has a major role to play as institutions adapt to the massive shift in learners’ preferences and expectations,” says Jesus Trujillo Gomez, Strategic Business Executive, Education & Research, Google Cloud. 

Feeling inspired? Let’s meet your EdTech challenges together and transform your data culture. Visit Google Cloud for education technology.

As software-defined vehicles continue to advance and the quantity of digital services grows to meet consumer demand, the data required to provide these services continue to grow as well. This makes automotive manufacturers and suppliers look for capabilities to log and analyze data, update applications, and extend commands to in-vehicle software.

The challenges the automotive sector faces can be quantified. A modern vehicle contains upwards of 70 electronic control units (ECUs), most of which are connected to one or more sensors. Not only is it now possible to exactly measure many aspects of vehicle performance, but new options become available. Using LIDAR (light detection and ranging), for example, vehicles are achieving higher levels of autonomy; this leads to a data stream from such demanding applications that may reach 25 GB per hour. For the in-vehicle processing of data, 100 million lines of software code may be present — more than a fighter jet. This in-vehicle code will have to be maintained with updates and new functionalities.

Access to the data will allow manufacturers to gain valuable insights into operational details of their vehicles. The use of this data can help to reduce costs and risks, increase ROI, support ESG initiatives, and provide valuable insights to develop innovative solutions and shorten the time to value for Electric Vehicle innovations.

Sibros’ Deep Connected Platform (DCP) makes it possible for these manufacturers to build and launch new connected vehicle use cases from production to post-sale at scale by connecting and managing all software and data throughout every life cycle stage. A key component of this platform is the Sibros Deep Logger that provides capabilities like the following:

• Full configurability of what to record, when to record it, and how fast to record it.
• High resolution timestamps of all Controller Area Network (CAN) messages.
• Dynamic application of live log configurations to receive new data points without deploying new software.

For example, properly analyzed engine data enables true predictive maintenance for the first time, which creates the option to repair or replace components before failure happens. Another example would be the evaluation of data regarding the use of certain in-car features with the goal to redesign its interior.

Two other components of the DCP are software updates and remote commands to ECUs. The DCP on Google Cloud enables seamless integration with any vehicle architecture and provides OEMs and suppliers with the platform to manage connected vehicle data at rest and in transit using a proven and secure way on a global scale.

OEMs can pull data through APIs provided by Sibros into Google Data Cloud (including BigQuery) to gain access to the rich information data sets provided by the DCP within their environment and blend this data with their first party data sets to provide value insights for their business. Some of the Connected Vehicle insights that DCP information enables are:

• Damage prevention, improved operation, or development of the next generation of engines with insights from complex analyses that could consider parameters like model, engine type, mileage, overall speed, temperature, air pressure, load, services, and more.
• The combination of electric vehicle battery usage data like charging cycles, engine performance, and battery age with contributing factors as the use of the air conditioning to determine if such factors contribute to hazardous battery conditions and for improved battery development.
• Cross-organization collaboration in R&D by the provision of information on all these metrics and more from real-world driving, like engine knock data and even tire pressure.
• Google Cloud’s unified data cloud offering provides a complete platform for building data-driven applications like those from Sibros — from simplified data ingestion, processing, and storage to powerful analytics, AI, ML, and data sharing capabilities — integrated with Google Cloud. With a diverse partner ecosystem and support for multi-cloud, open-source tools and APIs, Google Cloud provides Sibros the portability and the extensibility they need to avoid data lock-in.

“Software has an ever increasing importance in the automotive world, even more so with electric vehicles and new mobility services. Google Cloud is partnering with Sibros to bring their award winning Deep Connected Platform to deliver high frequency, low latency over-the-air software updates, data logging & diagnostics capabilities to our automotive customers, leveraging the security and scale of Google Cloud. This is revolutionizing everything from development cycles to business models and customer relationships.” — Matthias Breunig, Director, Global Automotive Solutions, Google Cloud

Through Built with BigQuery, Google Cloud is helping tech companies like Sibros build innovative applications on Google’s Data Cloud with simplified access to technology, helpful and dedicated engineering support, and joint go-to-market programs.

“Sibros is looking forward to partnering with Google Cloud, which will enable vehicle manufacturers and suppliers to reach the next level in their use of data. Sibros solutions for Deep Data Logging and Updating on the Google Data Cloud, combined with Google BigQuery, will help them to mitigate risks, reduce costs, add innovative products, and introduce value-added use cases.” — Xiaojian Huang, Chief Digital Officer, Software, Sibros

Sibros and Google Cloud are driving Connected Mobility transformation to help our customers accelerate R&D innovation, power efficient operations, and unlock software-defined vehicle use cases with a full stack connected vehicle platform. Click here to learn more about Sibros on Google Cloud.

Hundreds of millions of residents of South East Asia have only limited access to banking and finance services. However, help is at hand. One of South East Asia’s largest fintech businesses, Ascend Money is using digital technologies to realize its mission of enabling as many people as possible to access innovative financial services and live better lives.

According to Ascend Money, 60 percent of the region’s 620 million residents do not have access to a full suite of financial services. Even a relatively small proportion of this market represents a big opportunity for the business.

Ascend Money’s offerings include the TrueMoney regional payment platform for underserved and digital consumers. The TrueMoney platform supports more than 40 million consumers across six countries: Cambodia, Indonesia, Myanmar, the Philippines, Thailand, and Vietnam.

“We found, based on value, ease of use, effectiveness, and the skills and adaptability of our own team members, BigQuery and other Google Cloud Platform services were the best fit for our business.”

– Abraham Jarrett, Head of Engineering, Ascend Money

TrueMoney also provides an e-wallet app that provides easy ways to top up mobile phones, undertake online shopping, and pay for products and services; a network of 65,000 branded shops; and international remittances, initially between Thailand and Myanmar. In addition, Ascend Money offers financial products to small to medium businesses.

Ascend Money is part of the South East Asian online business Ascend Group, which also operates e-commerce, e-procurement, data centers, cloud services, fulfilment, and digital marketing services.

Cost is a key criteria

Ascend Money initially started operations using physical infrastructure and on-premises workforce productivity applications. However, as the business grew its customer base and expanded into new markets, its technology leaders began to explore options to improve value for money; reduce the maintenance load on in-house team members; improve its data management and analysis; and collaborate more effectively.

“Operating our own on-premises infrastructure entails a higher cost of ownership and maintenance, as well as requiring us to scale up our hardware as needed,” says Abraham Jarrett, Head of Engineering, Ascend Money. “We conducted an evaluation and found that moving to the cloud would deliver a range of benefits.”

G Suite and Google Cloud Platform the best fit

The business evaluated solutions available in the market and opted to move to G Suite and Google Cloud Platform.

“Moving to Google Cloud Platform was an optimization exercise, with lowering our costs our primary goal, and achieving better performance an added benefit,” says Jarrett. Google Cloud Platform monitoring, diagnostic, and analytics tools have enabled Ascend Money to reduce its infrastructure spending, becoming more efficient and cost-effective in the process.

“Managing software is a big cost for us. Through G Suite, we are significantly reducing our software deployment, licensing, and repair costs.”

– Abraham Jarrett, Head of Engineering, Ascend Money

The Ascend Money team saw Google Kubernetes Engine as enabling a seamless way of transitioning from an on-premises data center to a cloud service. “We considered industry trends such as what people were adopting and who we could hire when making our decision,” says Jarrett. “Engineering teams are focusing on using Kubernetes open source container management at scale and as a way of doing business, which was attractive to us.

“Google Kubernetes Engine presented the easiest way to manage and orchestrate our containers, and drive us away from our existing infrastructure.”

BigQuery best for cost and ease of use

Ascend Money also reviewed data infrastructure solutions, with its business intelligence and data platform teams considering a range of options. The teams quickly ruled out an on-premises solution due to the capital investment required and opted for a cloud service. Following a rigorous evaluation of Google Cloud Platform against the services offered by another cloud provider, Ascend Money opted to run on Google Cloud.

“We found, based on value, ease of use, effectiveness, and the skills and adaptability of our own team members, BigQuery and other Google Cloud Platform services were the best fit for our business,” says Jarrett. The business is now running an architecture comprising a BigQuery analytics data warehouse; Cloud Storage to store raw and archive data; Cloud Dataflow to process stream and batch data, and Cloud Pub/Sub for event ingestion and delivery.

“We’re expanding our utilization of BigQuery and other services on a daily basis,” says Jarrett.

Ascend Money is also using a range of Google Cloud Platform services for the infrastructure outside its data platform, including Stackdriver logging and monitoring; Cloud KMS to manage cryptographic keys for its cloud services, Cloud Build to undertake continuous integration, delivery, and deployment; Cloud DNS to provide domain name system services; and Cloud Functions to enable its developers to run and scale code in the cloud.

With Google Cloud Platform, Ascend Money is now processing about 12GB of batch data per day and streaming data from about 200 data marts per day in Thailand alone.

Cost effective scalability and faster to market

Google Kubernetes Engine has enabled the business to scale and deliver to market faster. “We can build on the platform, take the application and container and deploy them to scale out,” says Jarrett. “The Google Kubernetes Engine orchestration mechanism that provides containerized, elastic scalability is extremely important in allowing us to manage costs and expend our effort efficiently. Through Kubernetes, we can write once and deploy everywhere.”

With Google Cloud Platform, the business has saved 3,000,000 THB (about US$90,000) in licensing costs and, through automation tools, reduced the time to complete infrastructure activities by 50 percent.

“We don’t have as many meetings since we deployed G Suite and we can work effectively in a distributed fashion.”

– Abraham Jarrett, Head of Engineering, Ascend Money

Ascend Money’s entire workforce is now using G Suite to collaborate and operate productively. The business is achieving a range of benefits including being able to get new team members up and running more quickly and reduced cost. “Managing software is a big cost for us,” says Jarrett. “Through G Suite, we are significantly reducing our software deployment, licensing, and repair costs.” Meanwhile, the shorter time to onboard team members to G Suite is paying off with improved productivity and an accelerated ability to collaborate.

Ascend Money team members primarily use Sheets, Slides, and Docs to create internal materials, including product requirement documents in Docs and workforce and project planning spreadsheets in Sheets.

The organization also uses Hangouts Meet to collaborate when working from different locations. “We don’t have as many meetings since we deployed G Suite and we can work effectively in a distributed fashion,” says Jarrett. “People can work from home and we have five regions plus Thailand where they can collaborate live on a document, such as a slide deck for board meetings or meetings with our chief executive officer, head of engineering, or other senior managers.”

20 hours per week saved

Jarrett describes the time savings of using web browser-based productivity software and G Suite as saving them an average of 20 hours per week. This has improved productivity and the quality of life for Ascend Money’s hard-working team, increasing overall staff satisfaction.

“The ability to work remotely is a big win for us,” Jarrett says. “Our team members can keep one computer at work and one at home and access the same information, they can work in a plane while it sits on the tarmac, or update a Google Doc or a Google Sheet in real time on their phone. They can work anytime, from any location, as long as they have an internet connection. They have less dead time, meaning more uptime.”

With Google Cloud Platform and G Suite, Ascend Money is ideally positioned to support growing demand for its fintech services in South East Asia, particularly among people with limited access to banking. “We have the agility and dynamism to support rising demand and look forward to continuing to work with Google to realize our business ambitions,” says Jarrett.

When ATB Financial decided to migrate its vast SAP landscape to the cloud, the primary goal was to focus on things that matter to customers as opposed to IT infrastructure. Based in Alberta, Canada, ATB Financial serves over 800,000 customers through hundreds of branches as well as digital banking options. To keep pace with competition from large banks and FinTech startups and to meet the increasing 24/7 demands of customers, digital transformation was a must. To support this new mandate, in 2019, ATB migrated its extensive SAP backbone to Google Cloud. In addition to SAP S/4 HANA, ATB runs SAP financial services, core banking, payment engine, CRM and business warehouse on Google Cloud. 

In parallel, changes were needed to ATB’s legacy data platform. The platform had stability and reliability issues and also suffered from a lack of historical data governance. Analytics processes were ad hoc and manual. The legacy data environment was also not set up to tackle future business requirements that come with a high dependency on real-time data analysis and insights.

After evaluating several potential solutions, ATB chose BigQuery as a serverless data warehouse and data lake for its next-generation, cloud-native architecture. “BigQuery is a core component of what we call our data exposure enablement platform, or DEEP,” explains Dan Semmens, Head of Data and AI at ATB Financial. According to Semmens, DEEP consists of four pillars, all of which depend on Google Cloud and BigQuery to be successful:

1. Real-time data acquisition: ATB uses BigQuery throughout its data pipeline, starting with sourcing, processing, and preparation, moving along to storage and organization, then discovery and access, and finally consumption and servicing. So far, ATB has ingested and classified 80% of its core SAP banking data as well as data from a number of its third-party partners, such as its treasury and cash management platform provider, its credit card provider, and its call center software. 
2. Data enrichment: Before migrating to Google Cloud, ATB managed a number of disconnected technologies that made data consolidation difficult. The legacy environment could handle only structured data, whereas Google Cloud and BigQuery lets the bank incorporate unstructured data sets, including sensor data, social network activity, voice, text, and images. ATB’s data enrichment program has enabled more than 160 of the bank’s top-priority insights running on BigQuery, including credit health decision models, financial reporting, and forecasting, as well as operational reporting for departments across the organization. Jobs such as marketing campaigns and month-end processes that used to take five to eight hours now run in seconds, saving over CA$2.24 million in productivity. 
3. Self-service analytics: Data for self-service reporting, dashboarding, and visualization is now available for ATB’s 400+ business users and data analysts. Previously, bringing data and analytics to the business users who needed it while ensuring security was burdensome for IT, fraught with recurrent data preparation and other highly manual elements. Now, ATB automates much of its data protection and governance controls through the entire data lifecycle management process. Data access is not only open to more team members but it is faster and easier to acquire without compromising security. And it’s not just raw data that users can access. ATB uses BigQuery to define its enterprise data models and create what it calls its data service layer to make it easier for team members to visualize their data.
4. AI-assisted analytics and automation: Through Google Cloud and BigQuery, ATB has been able to publish data and ML models that provide alerts and notifications via APIs to customer service agents. These real-time recommendations allow customer service agents to provide more tailored service with contextualized advice and suggested new services. So far, the company has deployed more than 40 ML models to generate over 20,000 AI-assisted conversations per month. Thanks to improved customer advocacy and less churn, the bank has realized more than CA$4 million in operating revenue. During the ongoing COVID crisis, the system was also able to predict when business and personal banking customers were experiencing financial distress so that a relationship manager could proactively reach out to offer support, such as payment deferral or loan restructuring. The AI tools provided by BigQuery are also helping ATB detect fraud that previously evaded rules-based fraud detection by using broader sets of timely and accurate data. 

Thanks to the speed and ease of moving data from SAP to BigQuery, ATB is using artificial intelligence (AI) and machine learning (ML) to do things it previously hadn’t thought possible, including sophisticated fraud prevention models, product recommendations, and enriched CRM data that improves the customer experience. 

Using the power of Google Cloud and BigQuery, ATB Financial has been able to draw more value from its SAP data while lowering cost and improving security and reliability. Speed to provide data sets and insights to internal team members has improved 30%. The bank also has seen a 15x reduction in performance incidents while improving data governance and security. Dan Semmens projects that the digital transformation strategy built on Google Cloud and BigQuery has both saved millions compared to its on-premises environment and has also realized millions in new business opportunities. 

Semmens is looking toward the future that includes initiatives like Open Banking and greater ability to provide real time personalized advice for customers to drive revenue growth. “We see our data platform as foundational to ATB’s 10-year strategy,” he says. “The work we’ve undertaken over the past 18 months has enabled critical functionality for that future.” 

Learn more about how ATB Financial is leveraging BigQuery to gain more from SAP data. Visit us here to explore how Google Cloud, BigQuery, and other tools can unlock the full value of your SAP enterprise data.