Keboola: Data Monetization Series - How data science can help

                       

Having access to the right data in a clean and accessible format is the first step (or series of steps) leading up to actually extracting business value from your data.  As much as 80% of the time spent on data science projects involves data integration and preparation.  Once we get there, the real fun begins.  With the continued focus on big data and analytics to drive competitive advantage, data science has been spending a lot of time in the headlines.  (Can we fit a few more buzzwords into one sentence?)

Let’s take a look at a few data science apps available on our platform and how they can help us into our data monetization efforts.

Basket analysis

One of the most popular algorithms is market basket analysis.  It provides the power behind things like Amazon’s product recommendation engine and identifies that if someone buys product A, they are likely to buy product B.  More specifically, it’s not identifying products placed next to each other on the site that get bought together, rather products that aren’t placed next to each,  This can be useful in improving in-store and on site customer experience, target marketing and even the placement of content items on media sites.

Anomaly detection

Anomaly detection refers to identifying specific events that don’t conform to the expected pattern from the data.  This could take the form of fraud detection, identifying medical problems or even detecting subtle change in consumer buying behaviors.  If we look at the last example, this could help us in  identifying new buying trends early and taking advantage.  Using the example of an eCommerce company, you could identify anomalies in carts created per minute, a high number of carts abandons, an odd shift in orders per minute or a significant variance in any other number of metrics.

Using a Data Prep Platform: The Key to Analytic Product Agility

                                                     

                                                                                      Guest post by Kevin Smith

For a product owner, one of the biggest fears is that the product you're about to launch won't get the necessary adoption to achieve success. This might happen for a variety of reasons— two of the most common are a lack of fit to the customers' needs and confusing design (it's just too hard to use!).

To combat the possibility of failure, many product owners have adopted the "agile" approach to building products that have enough functionality to meet to minimum needs, but are still lean enough to facilitate easy change.

As a data product builder — someone building customer-facing analytics that will be part of a product — the needs are no different but achieving agility can be a real challenge. Sure, every analytics platform provider you might consider claims that they can connect to any data, anywhere, but this leaves a lot of wiggle room. Can you really connect to anything? How easy is it? How hard is it to change later? What about [insert new technology on the horizon here] that I just heard about? If you want to build an agile data product, you've got a tough road ahead... as I found out.

Recently I started working on the analytics strategy for a small start-up firm focused on providing services to large enterprises. As they delivered their services, they wanted to show the results in an analytics dashboard instead of the traditional PowerPoint presentation. It would be more timely, easier to deliver, and could be an on-going source of revenue after an engagement was completed. As I spoke with the team, a few goals surfaced:

  1. They wanted to buy an analytics platform rather than build from scratch. The team realized that they would be better off developing the methodology that would differentiate them from the competition instead of creating the deep functionality already provided by most analytics platforms.
  2. The system had to be cost-effective both to set-up and to operate. As a start-up, there simply wasn't the cashflow available for costly analytics platforms that required extensive professional services to get started. The product had to be flexible and "configurable" by non-Engineers. With little to no budget for an Engineering staff, the team wanted a BI platform that could be configured easily as customer needs changed.
  3. Up and running quickly. This company had customers ready to go and needed a solution quickly. It would be essential to get a solution in front of the customers NOW, rather than try to migrate them to a new way of operating once the dashboards were ready. Changes would certainly be needed post-launch, but this was accepted as part of the product strategy.

None of this seemed to be impossible. I've worked on many data products with similar goals and constraints. Product teams always want to have a platform that's cost-effective, doesn't strain the technical capabilities of the organization, is flexible, and is launched sooner rather than later. It was only after a few more conversations that the problem arose: uncertain data sources.

Most data-driven products work like this: you've got a workflow application such as a help desk application or an ordering system that generates data into a database that you control. You know what data is flowing out of the workflow application and therefore, you understand the data that is available for your analytics. You connect to your database, transform the data into an analytics-ready state, then display the information in analytics on a dashboard. The situation here was different. As a services company, this business had to operate in a technology environment dictated by the customer. Some customers might use Salesforce, some might use Sugar CRM. Still others might use Zoho or one of the myriad other CRM platforms available. Although the team would structure the dashboards and analytics based on their best practices and unique methodology, the data driving the analytics product would differ greatly from customer to customer.

Keboola: Data Monetization Series Pt. 2

             

As we examined in part 1 of our Data Monetization blog series, the first step to increasing revenue with data is identifying who the analytics will be surfaced to, what their top priorities are, what questions we need to ask and which data sources we need to include.  For this blog, let’s take a look at what tools we will need to bring it all together.  

With our initial example of a VP of Sales dashboard, fortunately the secondary data sources (NetProspex, Marketo and HubSpot Signals) all integrate fairly seamlessly with the Salesforce CRM.  This should allow for some fairly straightforward analytics built on top of all the data we’ve aggregated.  If we pivot over to our CMO dashboard, things get a bit murkier.

Although our Marketo instance  easily integrates with Salesforce, the sheer volume of data sources that can provide insight to our marketing activity makes this project a much more daunting ask.  What about our social channels, Adobe Omniture, Google Ads, LinkedIn Ads, Facebook Ads, SEO as well as various spreadsheets.  In more and more instances, especially for a team managing multiple brands / channels, this number can easily shoot into the dozens.

Keboola: Data Monetization Series Pt. 1


When a company thinks about monetizing data, the things that come to mind are increasing revenue, identifying operational inefficiencies or creating a new revenue stream.  It’s important to keep in mind that these are the results of an effective strategy but can't be the only goal of the project.  In this blog series, we will exam these avenues with a focus on the added value that ultimately leads to monetization.  For this blog, lets look at it from the perspective of creating executive level dashboards at a B2B software company.

Who will be consuming the data and what do they care about?

Before we jump into the data itself, take a step back and understand who the analytics will be surfaced to and what their challenges are.  Make profiles with their top priorities, pain points and the questions they will be asking.  One way to get started is to make a persona priority matrix listing the top three to five challenges for each (ex. below.)

Screen Shot 2016-01-16 at 15642 PMpng

Once the matrix is laid out, you can begin mapping specific questions to each priority.  What answers might help a VP of Sales increase the effectiveness of the sales team and ultimately revenue?

  • What do our highest velocity deals look like (vertical, company size, who’s involved)?

  • What do our largest deals look like?

  • Where do our deals typically get stuck in the sales process?

  • What activities and actions are our best reps performing?

Top 3 challenges of big data projects


The Economist Intelligence report Big data evolution: forging new corporate capabilities for the long term published earlier this year provided insight into big data projects from 550 executives across the globe. When asked what their company’s most significant challenges are related to big data initiatives, maintaining data quality, collecting and managing vast amounts of data and ensuring good data governance were 3 of the top 4 (data security and privacy was number 3.) Data availability and extracting value were actually near the bottom. This is a bit surprising as ensuring good data quality and governance is critical to getting the most value from your data project.

Maintaining data quality

Having the right data and accurate data is instrumental in the success of a big data project. Depending on the focus, data doesn’t always have to be 100% accurate to provide business benefit, numbers that are 98% confident is enough to give you insight into your business. That being said, with the sheer volume and sources available for a big data project, this is a big challenge. The first issue is ensuring that the original system of record is accurate (the sales rep updated Salesforce correctly, the person filled out the webform accurately, and so forth) as the data needs to be cleaned before integration. I’ve personally worked through CRM data projects; doing cleanup and de-duping can take a lot of resources. Once this is completed, procedures for regularly auditing the data should be put in place. With the ultimate goal of creating a single source of truth, understanding where the data came from and what happened to it is also a top priority. Tracking and understanding data lineage will help identify issues or anomalies within the project.

Collecting and managing vast amounts of data

Before the results of a big data project can be realized, processes and systems need to be put into place to bring these disparate sources together. With data living in databases, cloud sources, spreadsheets and the like, bringing all the disparate sources together into a database or trying to fuse incompatible sources can be complex. Typically, this process consists of using a data warehouse + ETL tool or custom solution to cobble everything together. Another option is to create a networked database that pulls in all the data directly, this route also requires a lot of resources. One of the challenges with these methods is the amount of expertise, development and resources required. This spans from database administration to expertise in using an ETL tool. It doesn’t end there unfortunately; this is an ongoing process that will require regular attention.

Ensuring good data governance

In a nutshell, data governance is the policies, procedures and standards an organization applies to its data assets. Ensuring good data governance requires an organization to have cross-functional agreement, documentation and execution. This needs to be a collaborative effort between executives, line of business managers and IT. These programs will vary based on their focusbut will all involve creating rules, resolving conflicts and providing ongoing services. Verifications should be put into place that confirm the standards are being met across the organization.

Conclusion

Having a successful big data project requires a combination of planning, people, collaboration, technology and focus to realize maximum business value. At Keboola, we focus on optimizing data quality and integration in our goal to provide organizations with a platform to truly collaborate on their data assets. If you’re interested in learning more you can check out a few of our customer stories.

KBC as a Data Science Brain Interface

The Keboola Data App Store has a fresh new addition. That brings us to total of 16 currently available apps, three of which provided by development partners.

This new one is called “aLook Analytics”, and technically it is a clone of our development project, a “Custom Science” app (not available yet, but soon!). It facilitates connection to a GitHub/Bitbucket repository of a specific data science shop, which you can “hire” via the app and enable them to safely work on your project.

This first instance is connected to Adam Votava’s company aLook Analytics (check them out at http://www.alookanalytics.com/).

How does it work?

Let’s imagine you want to build something data-science-complex in your project. You get in touch with aLook and agree on what it is you want them to do for you. You exchange some data, the boys there will do some testing on their side, set up the environment and once they’re done, they’ll give you a short configuration script that you will enter into their app in KBC. Any business agreement regarding their work is to be made directly between you and aLook, Keboola stays on the sidelines for this one.
When you run the app, your data gets served to aLook’s prepared model and scripts, saved in aLooks repository get executed on Keboola servers. All the complex stuff happens and the resulting data gets returned into your project. The app can be (like any other) included in your Orchestrations, which means it can run automatically as a part of your regular workflow.

The user of KBC does not have direct access to the script, protecting aLook’s IP (of course, if you agree with them otherwise, we do not put up any barriers).

Very soon we will enable the generic “Custom Science” app mentioned above. That means that any data science pro can connect their GitHub/Bitbucket themselves - that gives you, our user, the freedom to find the best brain in the world for your job.

Why people and not just machines?

No “Machine Learning Drag&Drop” app provides the same quality as a bit of thought by a seasoned data scientist. We’re talking business analytics here! People can put things in context and be creative, while all machines can do is to adjust (sometimes thousands of) parameters and tests the results against a training set. That may be awesome for facial recognition or self-driving car AI, but in any specific business application, a trained brain will beat the machine. Often you don’t even have enough of a test sample so a bit of abstract thinking is critical and irreplaceable.

How we "hacked" Vizable

Tableau unveiled their new Vizable app the first full day of the Tableau User Conference 2015 (A.K.A. TC-15) to much oohs and aahs. Vizable is a tablet app that allows users to take data from an .xls or .csv file and easily interact with it right on their tablet. It is unparalleled in its ease of use and intuitiveness, providing an exciting new way to consume data and drive insights. More information here: http://vizable.tableau.com/

As soon as we saw it, the Keboola team thought, “What an exciting way to use data from Keboola Connection - if only we could send data to it immediately to test it!” The app is built to accept .xls and .csv files that are physically present on the iPad it runs from, so at a glance, it is completely and utterly off-line. We immediately wondered if Keboola Connection - due to its integration with DropBox and Google Drive - could make Vizable the ultimate, on-the-go data visualization app.

(a little bit of frantic testing later)

Yeah! We can easily schedule pushing data into the iPad using our existing integrations. We didn't have to write a single line of code and already during the conference we were able to play with #data15 mentions we’d pulled in through Keboola Connection, with fresh data being automatically pushed into the iPad every 30 minutes.

We eagerly shared our success with the Vizable team and started showing conference attendees and members of the Tableau team just how we’d made it all happen! It was great to receive a string of visits from the whole Vizable crew all the way up to Dave Story, VP of Mobile and Strategic Growth, and Chris Stolte, the Chief Development Officer. What a thrilling way to educate the Tableau folks on all the cool stuff Keboola does with their tool and for their customers.

Get in touch with us if you want to know more!

Agency - get rid of pivot tables !

During my midnight oil hours and rumbling through out our internal systems, I have come across the ZenDesk tickets that our data analysts are closing for one of hour clients - H1 agency (part of GroupM).

At H1.cz they have created a report in GoodData which is called “non active campaigns”. It contains one metric, 5 attributes of type data, client, etc. and 4 filters (time, client’s agency, etc….) - It sounds super simple, but let’s take a closer look.



What it does, it gives you back a table, which is a wet dream of any and all agencies out there. You can see “anything” across all of the advertising channels. I mean “anything." In this particular case, they’ve created a report of non active campaigns. After some time this is a very good example of an output that is very hard or impossible to achieve in things like Tableau, SAP, Chartio, periscope.io or RJMetrics. Rock&Roll of the multi-dimensional BI system! You need to live it to believe it and to actually understand it.

Bellow is the data model (non readable on purpose), the yellow ovals are the things on top of which you count and you can see them in the context of green ones:


Karel Semerák from H1.cz has prepared this report. I bet he has no clue what mega machine he put into works so it would actually produced this. GoodData has based on the physical data model, definition of metrics and report context generated 460 rows of SQL in the datawarehouse which propells the system. 

Just imagine that there is a real person that tries to do this report by the hand (totally ignoring the incomprehensible amount of data), he has to do lots of small tasks (look inside AdWords, find the active clients, count number of their campaigns, compare to CRM data for paid invoices, create temporary pivot table, etc.)  and every little task could be represented by the rectangle inside this picture:


It all comes to almost 90 totally different tasks each taking from a minute to 3 days when done by hand. Try to explain this workflow to a Teradata consultant and you will spend a week just explaining what you want, try it with IBM Cognos expert and…well you get the picture.
And one more thing, with GoodData you do it yourself and don’t have to wait another month for the expert nor pay 5 digits sum for one report.

Well played, GoodData & multi-dimensional BI! 

But for a moment let’s forget about this one report. H1.cz has already prepared over 400 of such reports. Try to produce that in Excel and you better have a hord of MS Excel devotees who work hard as robots and are precise as robots. Last time I have seen something like this was years back at OMD. It was a mega office and all of the people inside have been producing pivot tables.

Talking about robots. If you are interested in counting the probability with which “data AI robots” will replace your job, take a look here.


Karel Semerák from H1.cz can stay cool though. He think about the data and the context instead of spending time on tasks where robots will always be better and that is one thing where robots will take some time to improve. Cognitive skills and context.

So next time your P/L starts nocking on your doors, think about giving your people the chance to creatively use their head and leave all the heavy lifting to robots. People aren’t the best at copy&paste or sorting through the AdWords report, but they are great at creative thinking and that is what you need in order to win over your competition.

Gorila Mobil - Data-Driven Business

In July 2014, O2 announced that it had acquired Gorila Mobile (virtual mobile operator). Gorila approached us at Keboola a couple of months before their official launch.  They had one goal: “We need to have a data-driven company and we want you to help us set it up.”

The brain behind Gorila is Roman Novacek, a brain that works a bit differently than yours or mine.

18 months ago

It was the morning of  23.4.2013 and I was on my way to one of the largest techhubs - TechSquare to see Roman. Back then Roman had started a company called Tarifomat which was offering its customers a way to find the best mobile operator deal and help them switch. Honestly, Tarifomat was a great idea with a very difficult execution path. Their sales funnel is verrrry long. Basically they get paid only a ½ year after the client switches and only in the case that he doesn’t cancel beforehand.  The path to getting paid is paved with unexpected traps like “the courrier that was delivering the SIM card hasn’t found the address” etc.  A perfect fit for us if the client could increase their margins by 30x. We rolled up our sleeves and proceeded with the project. It was a success. It had to be, our VP of Propaganda wrote that companies can count on us and we have to honor that promise.

Tarifomat got a perfect overview of their whole funnel (up to 1500 requests a day). Roman says that it was the first time that he actually understood what was going on inside the company.

7 months later I got a call, it was Roman. He was being as secretive as James Bond and mysteriously speaking about some new virtual operator, but couldn’t tell me more, only that the plan was to design the company from the ground up as a data-driven company. Once somebody starts to send these kinds of signals, I can’t help it, but I lose my ability to focus on anything other than “new data-driven company”. Well, it looked just like lot of talk, but shortly after that came the walk. Roman sent us the first payment and right after the brief, we began meetings and planning what exactly we would be solving together.

Gorila was another virtual operator (inside the O2 network) and they tried to be very cool (check out the YouTube channel). But being cool is not the only ingredient for success….you need more….

With our help Roman put together the daily dashboards which mapped out the full acquisition channel down to each campaign/media/type/position/brand message/product. The O2 team was taken aback when they saw that. The number of activated SIM cards was growing, expenses were falling - everybody was happy, champagne flowing everywhere…. Only Roman’s team wasn’t celebrating. People weren’t actually using the SIM cards as they had envisioned inside Gorila Mobile. Now what ???

Friday afternoon:  "Let’s dig into the GoodData dashboards and solve this!"

Sunday evening: Claim "Gorila mobil - the most of internet, FUP you!" changed to "5 Kč/hr for calls and all the data you need".

A complete switch in brand positioning, based solely on data !  I get shivers running up my spine just thinking about that. While we were chilling in our offices, playing ping pong; Romans’ team was rocking it! 5Kc worked! - they got enough data to support their further visions; they were bold and full of energy.  

Roman has a vision that data describes the now as it is and that we should use that knowledge to validate strategic directions and decisions.

And we can see exactly the same pattern in DameJidlo. Gorila mobil is soaked deep down in data and it works. “There was no time to hide anything; everybody from the O2 callcentre to investors and partners has full access to all data” - daily orders, comparisons, value of the orders, SIM activations, number of customers and their behaviour, how frequently/and where they top-up their SIM cards, etc.

Unfortunately, this great ride lasted only 3 months. The Gorila project was over, so successful that Telefonica decided to buy it and incorporate it inside the O2 structure.

Roman moved on into a new project, and Keboola was ready. Anyhow, who can say you have a iPhone cover from the real cherry wood? We are very interested to see how they will handle the tricky things like life time warranty for the bamboo iPad cover and what role data will play in that business.

I caught Roman during his trip through China where he was stuffing himself with chicken feet - so here’s a quick Google Docs style interview :)

PS: Roman, what was the hardest thing in the beginning of Gorila ?

RN: Convincing O2 that we have to be agile and have NO time for endless meetings. We wanted to focus 100% of our time and energy on marketing and we knew we needed the company to be 100% based on data.  In the beginning no one believed this vision inside O2. Today, (after the Gorla acquisition) O2 wants to have the same system as we had (using the sales / activation/ channels activation data from yesterday). Dusan Simonovic and Jiri Caudr are the stakeholders and I hope they will be successful with that. When you know what is going on inside the company, you don’t have to speculate . That gives you real power to make decisions and work hard to achieve you goals; because you know exactly WHAT you’re doing and WHY you’re doing it. No stumbling in the dark. That’s how you oddelis zrno od plev….

PS: What do you mean by “odděluje zrna od plev”?

RN: Well, you can have lots of excuses when you don’t have the data. You can come up with excuses about things that went wrong when you don’t have data to show. Investors have no way to prove you wrong. At least in short term. You can argue that the market has changed, some externalities have worked against you, etc.  Once most of your decisions are firmly based on data and anybody can see the results on an ongoing basis, you literally put your skin in the game. If you f..ck something up, anybody can see in the data what happened. What were the circumstances before the decision and how it looks right now. I love this. I got addicted to data driven business and now I can’t do it any other way. My head just works this way :)

PS: This was your second project with Keboola. How was it for you working with us again?

RN: Once I convinced my partners to build a “metrics driven company” the hardest part was to get all the data sources. Network information, info from marketing tables, Google Analytics, distribution and logistics data like post office, couriers, CMS, etc.  We got lots of help from Martin Hakl and is company Breezy. They did our web and all the data extractors so the data could flow to Keboola.

PS: Could you show us something?

RN: Yep, I have smuggled the axis a bit….Now you will ask what it is and how we worked with it, right ? :)  What you can see in the report is the SIM cards activation in time. The dotted lines are linear extrapolations - trends - so you can see the general trend, growing or stagnation. We have this report on everybody’s dashboard and we can filter it according to the channel where SIM card was activated (for example large newspaper stand network, post offices, lottery terminals, etc.)  Exactly in the same way you can see what activations we have according to a marketing channel. If you click on any point inside the report another dashboard opens and you can see how much money we get from that particular set of activations and how these people behave. It’s hard to describe, it is much better to show in reality :)

PS: My favourite question is to ask people if they had any “aha moment.” The point at which you just realize that anything you’ve done until this point was wrong and you have to go 180 degrees different direction. Do you have a moment like this?

RN: We were spending around 1.5M / month on advertising. Marketing wise, our ads did perform super well! When we drilled through the data we noticed that we had some campaigns that were totally bad and dragged down the overall average for our campaigns. The interesting thing was that you couldn’t see this when you looked at total campaigns because we had some campaigns which were super extra good and they minimised the deviation. If we didn’t have the data, we couldn’t have discovered this at all. We had some extra great campaigns and some shitty ones, but the average was OK. We could dig into the details and discover the bad performers, so we can turn them down and start all over again the next day. Every day we have sent out over 500SIM cards and we knew exactly how much they cost us, how long it will take them to connect to the network, how much they’re gonna spend and how long they will stay with us. We could have calm night dreams, because we had data :)

PS:  Now you’re data guy forever?

RN: You got it buddy! :-) In any company I start the data analytics will be the first thing that I will be taking care off. Once we see inside the data and what’s going on inside the company, we are better able to take risks and test new things.



GoodData XAE: The BI Game-Changer (3rd part)

For previous part (2/3), continue here


Discovering the value you can’t see.

Creating a query language is the most complicated task to be solved in BI. It’s not about saving big data, not about their processing, nor about drawing graphs and making API to have a good cooperation with our clients. You cannot buy a query language nor program it in a month.

If the query language gets too complicated the customer won’t manage to work with it. If the query language gets too stupid the customer won’t manage to work with it the way he needs to. GoodData has a simple language to express any complicated questions about the data. At the same time, it has a device that helps it to apply the language to any complicated BI project (or logical data model). In the case of GoodData it has already been mentioned that MAQL/AQW – in my point of view- is the one that is irreplaceable. Furthermore, guys from Prague and Brno – Tomáš Janoušek, David Kubečka and Tomáš Jirotka have widened the AQE with a set of mathematical proofs (complicated algebra) that allow us quick tests of whether the new functions in AQE apply to any type of logical models. That’s how GoodData makes sure that the translations between (MAQL) metrics and some SQL in the lower databases are correct. AQE then helps a common user to overcome the chasm that separates him from low-level scripting.

UPDATE 17. 11. 2013: MAQL is a query language that is translated with MAQL interpreter (before known as QT – “Query Tree” engine) into a tree of queries using the basis of logical model (LDM). These queries are actually definitions of “star joins” in which “Star Generator” (SJG) creates its own SQL queries in DB backend according to the physical data model (PDM – lays below LDM). The whole thing was created at the beginning by Michal Dovrtěl and Hynek Vychodil. The new implementation of AQE further helped to lay all of this onto a solid mathematical basis of ROLAP algebra (which is similar to relation algebra).

After weeks of persuading and yes, bribes, I managed to beg lightly censored examples of queries that AQE creates out of metrics I wrote for this purpose. I guess this is the first time anyone has actually published this....

For a comparison I used the data model out of the Report Master course in Keboola Academy and made this report from it:

The right Y-Axis on the graph shows me how many contracts I have done in Afghanistan, Albania, Algeria and American Samoa in the last 13 months. On the left Y-Axis I can see with a blue line how much regular income my salespeople have brought me and the green line indicates how much was the median sales in a given month (the inputs are de-facto identical with the table at from Part 1 of the previous blog posts).

The graph then shows me three metrics (as per the legend below the graph):

  • "# IDs” = SELECT COUNT(ID (Orders)) – counts the number of components.

  • “Avg Employee” = SELECT AVG(revenue per employee) – counts the mean of (auxiliary) metrics counting the sum of turnover to salesperson.

  • “Median Employee” = SELECT MEDIAN(revenue per employee) – counts the median of (auxiliary) metrics counting the sum of turnover of salespeople.

and the auxiliary metrics:

  • "revenue per employee” = SELECT SUM(totalPrice (Orders)) BY employeeName (Employees) – counts the values of components (some sales) at the level of salesperson.

For the most part, everything explains itself – maybe except “BY” which states that the money “totalPrice  (Orders)” is counted per salesperson and not chaotically within itself. I dare say that anyone who is willing and tries MAQL even a little bit is going to learn (or for that matter we can teach it to you with Keboola Academy any time☺).

And now the most important thing... see below how AQE translates to the following SQL:

With a little bit of exaggeration we can say that creating my report is actually quite difficult but thanks to AQE, it does not bother me at all.


If these three hypotheses are valid:

  1. If GoodData won’t earn me a bunch of money, I won’t use it.
  2. I will earn a bunch of money, but only by the use of a BI project created to suit MY exact needs.
  3. BI that is created to suit MY exact needs is a complex matter that we can only manage with AQE.

… then the basis of the success of GoodData is AQE.

A footnote: the before mentioned MAQL metrics are simple examples. Sometimes it is necessary to build the metrics so complicated that it’s almost impossible to imagine what must happen to the background data. This is an example of metrics from one project where analytics stands upon the unstructured texts. Metrics counts the conversation topics in current time by moderators:

Lukáš Křečan once blogged (CZ) that people are the greatest competition advantage of GoodData.

Translation: “Our biggest competitive advantage is not a unique technology that no one else has. The main thing is people. ”

People are the base. We cannot do this without them; it’s them who create the one and only atmosphere in which unique things are founded. However, one and the other are replaceable.  The biggest competition advantage of GoodData (as well as the intellectual property) is AQE. If we didn’t have it the user would have to click the reports in closed UI that would take away the essential flexibility. Without AQE, GoodData would classify itself with Tableau, Bime, Birst and others. It would become basically uninteresting and it would have to compete strongly with firms who build their own UI over “Redshifts”.

AQE is an unrepeatable opportunity to get ahead of the competitors who then are only going to lose. No one else is able to implement their own new function into product with arbitrary data in arbitrary dimensions while analytically proving and testing the validity of their implementation.

The line between the false image of, “this cool dashboard is very beneficial for me” and the “real potential that you can dig out of the data” is very thin… it’s name is customizing. It’s an arbitrary model for arbitrary data and arbitrary calculations over it. It can be called an extreme. However, without the ability to count a natural logarithm out of a share of figures of two time-periods over many dimensions, you cannot become a star in the world of analytics. AQE is a game changer on the field of BI and only thanks to it, GoodData redefines rules of the game. Today a general root, tomorrow K-means… ☺  

Howgh!