Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

(info) Overview

This is a document to highlight all the data enhancements we can do to achieve automated offer measurements.

📸 Current State

We use the following tables in data to use toward offer measurement.

Table

Use

Comments

dydb.offers

Has all of the metadata for all digital offers in the system

  • We do not have complete data to determine the following things :

    • What AUV Categories does the offer drive

    • If Definitions are changed then log of different names and rules

    • How much Discount and the tag that differentiates between points and $ and % and nX is incomplete

    • Objective of this offer - sanity field that tells us what this offers id for .. eg- lapsing , trial , cross sell etc..

    • Secondary Category of Offer - also comes from sanity and tells us if the mechanism is only applicable on a specific action ( eg - applicable to only scan and pay / or automatically aplies for birthday etc. )

    • We have observed that there are some missing offers in the dydb.offers table that exist in the sysb.weeklyoffers table ( checking this and making sure its not a timing issue when new offers are created )

dydb.weeklyoffers

Offers list that is sent out by the weekly targeted offer models

  • We do not have a log of when an offer is sent out Vs not , we rely on redemptions to gather that information

  • we have a snapshot of current week, where a flag set to 1 signifies that the offer is currently active

dydb.new_offer_product_mapping_added_l3_new_names

Created manually by the offer teams and not maintained

  • this table is manually created and fulfils some of the requirements of metadata, but ideally , we would need not to rely on manual tables and rely only on the offer table for metadata

prodrt.curated_points_events

Table of all points transactions

  • Apart from its primary purpose of being the points transactional table, This is the only table that determines if a guest has completed a challenge (i.e points were issued under the “challenge complete” tag )

prodrt.curated_trans_events_new

Loyalty Transactions table

We use this for getting transactions attached to an offers , associated discounts and sales, guest and transaction counts

analytics.base_offer_log

Log table created to be a table to determine a log of all offers sent to a guest

analytics.ca_challenge_campaign_log

Log table created to be a table to determine a log of all challenges sent to a guest

  • No labels