Quesry service, when to use it?

Question

On a project we are unsure whether or not to purchase the query service. In what scenarios can the query service be used? is it possible to have some practical examples that help to understand when it is actually necessary to have this service?

I imagined the following two cases:

1. Do complex searches on datasets (example with the use of JOIN on individual schema, event and lookup)
2. insert the results of the research of point 1 in a dataset at time intervals. To create segments based on the data entered in the dataset through the JOINs (point 1)

Does it make sense to buy the query service for the two scenarios I have illustrated? are there any other examples that can make us understand the importance of query service?

Kishore_Reddy · Accepted Answer

Hey @gprime84

Hope you are doing well!

Great question!

Here are my two cents:

Both the scenarios you have mentioned could be use cases to acquire Query Service, but it's directly proportional to the varitety of data sources and complexity of relationships between the data tables ingested. If your enterprise already has a system or infrastructure to bring all relevant data together into one place, where you can data analytics (including insights), advanced segmentation, predictive modeling - then you might not require Query Service.
Else, I recommend to use Query service, since there are several (time and effort-saving) benefits with Query Service.
For instance, Adobe defined functions make it very easy to run complex queries, schema based data storage and a well-defined identity graphs enable seamless querying and less data modeling (while querying)
Icing on the cake is, ways to plug-in queried results to a Business Intelligence platforms such as MS Power BI and Tableau is pretty easy & OOTB.
Eventually, Query service won't be a new thing into an enterprise, since it supports a few popular desktop clients for querying. So it won't be hard for existing staff members to invest time in learning, it will be more of a business as usual (BAU) case. PLUS, query service comes with full scale API functionalities too!

Let me know if my thoughts aren't making sense, very happy to discuss more on the subject 🙂

Thank you,

Kishore

DavidSlaw1 · Answer

It does make sense. Very few companies with have ALL necessary data curated and enhanced with all required and potential analytic attributes for identifying segments. Moreover, the speed at which attributes can be created in query service is likely faster than the technical investment to do at the enterprise source level (Discover, Requirements, Build, Test, Deploy). This is especially true for attributes or segments for testing that may be removed or revised if they do not work as planned. No point in paying teams of people to integrate and create attributes that fail to generate value and need to be tossed. Once winning attributes are discovered, that is the right time to push their requirements upstream.

I have also used the Query Service to flatten data sets from dimensional models to avoid the number of joins in my profile merge rules. Could this be done outside AEP? Certainly if people, tools, and skills are also available to do the work given project time constraints. In my example, it would have taken a couple weeks and at least that many development hours with another technical team to have them implement the data flattening. I did it with Query Service in an afternoon.

It can get more complex if you are also using the Data Science Workspace (DSW). Much of work done in Query service can be done in DSW. DSW is a bit more tedious to set up analytic services that provide similar functionality to scheduling queries and required skills are more than SQL.

Best Regards,

David

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded