The 2/5/16 mark should be shown in this graph to better illustrate that there really was a week there... just nothing happened.
A date axis should show all marks, not just those when data exists
When creating a report where the X-axis is a date, I think the axis should work more like the behavior I see in Excel or Tableau. In the example I have included here, the account actually had activity for 4 weeks, then [i]no activity for the week of 2/5/16, followed by activity the week of 2/12/16.
The 2/5/16 mark should be shown in this graph to better illustrate that there really was a week there... just nothing happened.
The 2/5/16 mark should be shown in this graph to better illustrate that there really was a week there... just nothing happened.
I wish SFDC did that too. If you have an interval with no records it drops the category.
Where does this data live? I think it may take some work but you can in theory get the result you want.
For instance, if it is the SFDC GainSight Usage object the reason it does not show is because there is no data for that day for that specific account. You could build a rule that fires before the data is loaded and it will basically push all zeros to the data points. Then when the usage data is loaded it will update the values where there are some. Thus giving you a 2/5 date with a 0 point.
If the data lives in the MDA you essentially do the exact same thing. Utilize the the customer info as the source object and grab the account id in the show. In the Action section do a load to MDA and make it an upsert. match the Account id to the MDA account ID. Then add custom field mappings for all the data points that you are pushing and push 0. Then add a custom field mapping for the date. and push the rule date. Have this run before you load data. Then when you load the data into the MDA run an update instead of an insert. Your identifiers will be account id and date.
Before doing any of this though it really needs to be determined what your source object is, how the data is being loaded, and is it an upsert or insert?
For instance, if it is the SFDC GainSight Usage object the reason it does not show is because there is no data for that day for that specific account. You could build a rule that fires before the data is loaded and it will basically push all zeros to the data points. Then when the usage data is loaded it will update the values where there are some. Thus giving you a 2/5 date with a 0 point.
If the data lives in the MDA you essentially do the exact same thing. Utilize the the customer info as the source object and grab the account id in the show. In the Action section do a load to MDA and make it an upsert. match the Account id to the MDA account ID. Then add custom field mappings for all the data points that you are pushing and push 0. Then add a custom field mapping for the date. and push the rule date. Have this run before you load data. Then when you load the data into the MDA run an update instead of an insert. Your identifiers will be account id and date.
Before doing any of this though it really needs to be determined what your source object is, how the data is being loaded, and is it an upsert or insert?
Also in theory this could all be done on your side before the data is sent/loaded into the MDA/usage object.
If I'm understanding you right Wayne, you're saying build an aggregate field in MDA with a daily cadence and a literal value?
While this works - and is a clever workaround - all Jeff would like to do is see when something is missing in every data set. To do your suggestion on all measures of all objects starts to become labor or data footprint prohibitive. Further, it's hard to know which items you would need to do this on... because you can't see what's not there as a definition of the problem.
For example, let's suppose we wanted to do a count on opportunities so you can track how much upsell your CSM influenced/started. You would may need a field for opps created, changed, closed, forecasted, close rate with CSM, close rate w/o CSM, etc etc. All would need different aggregate/calculated fields
Having a reporting suite which can build a grouping with no records would greatly enable admins to nimbly identify trends as we navigate various reporting requests.
While this works - and is a clever workaround - all Jeff would like to do is see when something is missing in every data set. To do your suggestion on all measures of all objects starts to become labor or data footprint prohibitive. Further, it's hard to know which items you would need to do this on... because you can't see what's not there as a definition of the problem.
For example, let's suppose we wanted to do a count on opportunities so you can track how much upsell your CSM influenced/started. You would may need a field for opps created, changed, closed, forecasted, close rate with CSM, close rate w/o CSM, etc etc. All would need different aggregate/calculated fields
Having a reporting suite which can build a grouping with no records would greatly enable admins to nimbly identify trends as we navigate various reporting requests.
Yes Matt to the have the cadence run daily or weekly, depending on how often they load data.
It may be a little labor intensive in the beginning. But, once you have everything setup it will run on its own. As long as everything is ran on time there will be no issue. And I would only suggest doing this on usage data and nothing else. As a weekly trend normally doesn't matter unless it is usage. And typically most people only have 1-3 different usage data objects that they trend on.
In your opps example is a little more detailed then you would need. Your first rule would run utilizing the account or customer info. You default all values to 0 and then have your rule run that captures/snapshots the information from salesforce weekly. This will be an update action. You wouldn't need different calculate fields or aggregates. If this isn't done already then there is no need for it. And if it was done then nothing would need to change.
for a few examples please read on
_______
Original way with loading to MDA:
-Data is uploaded to MDA, typically an upsert but may be an insert
-This data is either then reported on or rolled up in some fashion
-If rolled up it is pushed to a new subject area(MDA objects) or to Usage Data Object in the MDA
Work Around
-Use Customer info as a source object in a rule and the Account ID and Load to MDA
-On action click the '+ Field Mapping' pick one of the measures and push a default zero
-Do this for all measures
-Data is uploaded to MDA, will need to be an upsert or update to update the default 0's we pushed
-This data is either then reported on or rolled up in some fashion
-If rolled up it is pushed to a new subject area(MDA objects) or to Usage Data Object in the MDA
_______
Original way with Opp from SFDC:
-Data is snapshotted from SFDC and pushed to MDA through a rule, I believe this is the point if any calculations/aggregations were performed would happen correct?
-Data exists in the MDA and it is either then reported on or rolled up in some fashion
-If rolled up it is pushed to a new subject area(MDA objects) or to Usage Data Object in the MDA
Work Around
-Use Customer info as a source object in a rule and the Account ID and Load to MDA
-On action click the '+ Field Mapping' pick one of the measures and push a default zero
-Do this for all measures
-Data is snapshotted from SFDC and pushed to MDA through a rule, If they originally had calculations/aggregations performed at this point then nothing will need to be changed as we are just running an update on the MDA and rewriting over the 0's if the data exists in salesforce
-Data exists in the MDA and it is either then reported on or rolled up in some fashion
-If rolled up it is pushed to a new subject area(MDA objects) or to Usage Data Object in the MDA
_______
Essentially all you are doing is base lining across the board before loading data. Then updating over the baseline.
The only issue I can think of running into is that it may mess calculated fields based off the raw data. Such as a percentage over a period of time in a calculated field to fire a CTA.
While I agree it would be nice to not have to do this it is the best work around I know of.
It may be a little labor intensive in the beginning. But, once you have everything setup it will run on its own. As long as everything is ran on time there will be no issue. And I would only suggest doing this on usage data and nothing else. As a weekly trend normally doesn't matter unless it is usage. And typically most people only have 1-3 different usage data objects that they trend on.
In your opps example is a little more detailed then you would need. Your first rule would run utilizing the account or customer info. You default all values to 0 and then have your rule run that captures/snapshots the information from salesforce weekly. This will be an update action. You wouldn't need different calculate fields or aggregates. If this isn't done already then there is no need for it. And if it was done then nothing would need to change.
for a few examples please read on
_______
Original way with loading to MDA:
-Data is uploaded to MDA, typically an upsert but may be an insert
-This data is either then reported on or rolled up in some fashion
-If rolled up it is pushed to a new subject area(MDA objects) or to Usage Data Object in the MDA
Work Around
-Use Customer info as a source object in a rule and the Account ID and Load to MDA
-On action click the '+ Field Mapping' pick one of the measures and push a default zero
-Do this for all measures
-Data is uploaded to MDA, will need to be an upsert or update to update the default 0's we pushed
-This data is either then reported on or rolled up in some fashion
-If rolled up it is pushed to a new subject area(MDA objects) or to Usage Data Object in the MDA
_______
Original way with Opp from SFDC:
-Data is snapshotted from SFDC and pushed to MDA through a rule, I believe this is the point if any calculations/aggregations were performed would happen correct?
-Data exists in the MDA and it is either then reported on or rolled up in some fashion
-If rolled up it is pushed to a new subject area(MDA objects) or to Usage Data Object in the MDA
Work Around
-Use Customer info as a source object in a rule and the Account ID and Load to MDA
-On action click the '+ Field Mapping' pick one of the measures and push a default zero
-Do this for all measures
-Data is snapshotted from SFDC and pushed to MDA through a rule, If they originally had calculations/aggregations performed at this point then nothing will need to be changed as we are just running an update on the MDA and rewriting over the 0's if the data exists in salesforce
-Data exists in the MDA and it is either then reported on or rolled up in some fashion
-If rolled up it is pushed to a new subject area(MDA objects) or to Usage Data Object in the MDA
_______
Essentially all you are doing is base lining across the board before loading data. Then updating over the baseline.
The only issue I can think of running into is that it may mess calculated fields based off the raw data. Such as a percentage over a period of time in a calculated field to fire a CTA.
While I agree it would be nice to not have to do this it is the best work around I know of.
Definitely an option for my process to go through and add a "zero record" for every possible customer/date combination. And, yes, I wish Salesforce could do this as well, but they don't and probably won't ever.
Conveniently, however, I'm not running a Salesforce report! I think a huge benefit of the Gainsight reporting engine and Matrix architecture is... well... It's not Salesforce! 🙂 So rather than having to workaround the limitation by augmenting the data, this would be nice to see, especially as a key argument for Matrix is the ability to handle large volumes of time-series data such as activity.
Conveniently, however, I'm not running a Salesforce report! I think a huge benefit of the Gainsight reporting engine and Matrix architecture is... well... It's not Salesforce! 🙂 So rather than having to workaround the limitation by augmenting the data, this would be nice to see, especially as a key argument for Matrix is the ability to handle large volumes of time-series data such as activity.
Sign up
If you ever had a profile with us, there's no need to create another one.
Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
Welcome to the Gainsight Community
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.