Components of a Real-Time Report

Reporting KPIs

When you plan to use a KPI in an RTR, configure the KPI as a read, calculated, or editable (written back) KPI.

The writeback KPIs defined in promotions and account plans are defined as Reporting read KPIs to read the written values from CG Cloud processing services (CGPS). To ensure that the writeback KPIs used in the promotions and account plans read the latest values, set the Reporting Type of the KPI as Read. If a KPI must be calculated before it’s shown in an RTR, set the Reporting Type as Calculated. You can set the Reporting Type of a read KPI as Calculated and the Reporting Type of a calculated KPI as Read. For example, Incremental Volume is a writeback calculated KPI on promotion level but you can set the Reporting Type of this KPI as Read. Similarly, Prices or Rates are read KPIs in account plans and promotions but you can set the Reporting Type as Calculated.

When designing average price, cost, and volume KPIs, keep in mind that the average price at the brand and category level is calculated by dividing aggregated cost by aggregated volume. Since only volumes and costs are written back and read directly in RTR, define them as Reporting Read KPIs, which are aggregated in hierarchy or grouping criteria. Since, average rates, prices, or percentage are always calculated in RTR, define them as Reporting Calculated KPIs, which are calculated at each hierarchy level.

Typically, the system calculates and writes account KPIs in CGPS one time in a day (when the relevant batch process is executed) and promotion KPIs when a promotion is saved.

Here are a few recommendations when you design KPIs for RTR:

• Define KPIs that don't change during the day as account KPIs. For example, baseline volume.
• Define KPIs that change during the day in promotions as promotion KPIs. For example, incremental volume.
• To display calculated values that can’t be stored, design them as reporting calculated KPI definitions. For example, profit margin.

For example, define three KPIs—baseline, incremental volume, and total volume. Here’s how you can design these KPIs:

• The baseline is used in account plans and RTR. Since, baseline doesn’t change during the day, define it as an account KPI.
• Incremental volume is used in promotions and RTR, and might change every time a promotion is adapted. So, define it as a promotion KPI and as a writeback KPI at the promotion level.
• Total volume used in account plans and RTR. Since the system calculates the total volume as the summation of base volume and incremental volume, define total volume as a calculated KPI. Total volume (calculated reporting KPI) = Base volume (account-level writeback) + Incremental volume (promotion-level writeback).

When a promotion is run and updated, the incremental volume is updated in CGPS and the system calculates the total volume. But, if you define the incremental volume as an account KPI, then the incremental volume isn’t updated in CGPS when the promotion is saved. So, to ensure that you get real-time updates in RTR each time a promotion is updated (without any KPI mappings or interfaces involved), define incremental volume as a promotion KPI.

Tip For better performance, configure writeback KPIs on higher product levels. So, the system reads values at higher product levels without reading and aggregating on the lowest product level.

Report Dimensions

Based on the report you want to create, create report dimensions to get promotion, product, tactic, or payment information from Salesforce or CGPS. Configure the list of attributes of the Promotion, Product, Tactic, or Payment objects that can be used in a report in an RTR dimension. For example, the Product dimension defines an ordered list of product levels corresponding to your product hierarchy and must contain all product levels in the product hierarchy in ascending order.

The types of RTR dimensions are:

• Product dimension: To define product hierarchy levels.
• Promotion dimension: To define the set of promotion attributes. Depending on the attribute definition (fielddb and fieldsf), the attributes are fetched from either CGPS or Salesforce.
• Tactic dimension: To define additional detailing attributes from the Tactic Product Condition object.
• Payment dimension: To define the set of payment attributes that can be available in payment reports.

Report Metadata

Report metadata is a configuration JSON that controls the behavior of the report. Configure report metadata to define the attributes, KPIs, and details of how data are filtered, aggregated, and shown in a report.

Report Dimensions

Based on the report you want to create, create report dimensions to get promotion, product, tactic, or payment information from Salesforce or CGPS. Configure the list of attributes of the Promotion, Product, Tactic, or Payment objects that can be used in a report in an RTR dimension. For example, the Product dimension defines an ordered list of product levels corresponding to your product hierarchy and must contain all product levels in the product hierarchy in ascending order.

The types of RTR dimensions are:

• Product dimension: To define product hierarchy levels.
• Promotion dimension: To define the set of promotion attributes. Depending on the attribute definition (fielddb and fieldsf), the attributes are fetched from either CGPS or Salesforce.
• Tactic dimension: To define additional detailing attributes from the Tactic Product Condition object.
• Payment dimension: To define the set of payment attributes that can be available in payment reports.

Report Metadata

Report metadata is a configuration JSON that controls the behavior of the report. Configure report metadata to define the attributes, KPIs, and details of how data are filtered, aggregated, and shown in a report.