This subsection discusses the data dependency from Party through CustomerAccount by tracing a sequence of relationships numbered 1 through 8. The diagrams here are snippets taken from the Customer Information - Extended View overview diagram.
Party to Key Customer Data Dependency Mapping
ARTS represents all people and organizations as parties. As shown in this diagram, a Party may be a Person, an Organization, a Household or an Anonymous entity. This part of the data model is concerned with Person and Organization. A given Party may play one or more PartyRoles such as employee, vendor, customer and many more. A Party is assigned to a given role through PartyRoleAssignment. A customer in ARTS is a party that fulfills the role of a Consumer and has completed a purchase at the retailer. The concept of consumer is used to enable life cycle tracking of parties before they make a purchase (i.e. when they are prospects). The concept of Consumer-Customer Lifecycle States is a way to identify, track and measure how consumers transition from being prospects to becoming customers. That transition involves a progression of ConsumerConversionStates (often referred to as the customer's journey) which upon completing their first purchase means they have reached a customer state (or in simpler terms they are now a customer). For more on the consumer to customer journey see the Consumer-Customer Journey section of this narrative.
Figure10 - Party to Key Customer Data Mapping Model
Customers may choose to share personally identifying information by registering with a retailer. By registering and sharing contact information a customer opts in to becoming a KeyCustomer. A KeyCustomer in ARTS is a customer that can be identified and who has agreed to provide contact information.
Customer Accounts Categories
By registering with a retailer, the KeyCustomer provides contact information that is a prerequisite to establishing an account relationship with the retailer. As shown here, ARTS supports a number of different kinds of CustomerAccounts. Each type of account involves different kinds of legal and financial obligations on the part of the customer and the retailer. Each type of account has a different expected lifetime. In the diagram below the blue outlined entity types are modified (they have new and modified attributes) in this new version of the data model. The green outline entities are new entity types being introduced in this release of the data model. This part of the Logical 07101 - Customer Information - Extended View subject area contains the most important changes from ARTS ODM V7.2 to this new version.
Figure 11 - Customer Accounts
The different types of customer accounts reflected in the entity model are distinguished based on the characteristics listed in the table shown here. This sub-typing of CustomerAccount represents a basic set of categories that retailers may extend as required. Retailers should use only those categories that are relevant to their business. The table shown here summarizes the account characteristics that distinguish one type of customer account from another. The account types covered in the ARTS ODM may be extended as required by retailers to meet their specific requirements.
Figure 12 - Customer Account Type Primary Characteristics
Beyond Customer Accounts - Membership and Rebate Programs
In the Customer Accounts entity model diagram there are two kinds of programs shown (numbers 6 and 7) for membership and rebates. The entities in the light green block identify, define and describe retailer customer membership programs that may include fee based and free loyalty based admission. These entities are generalized versions of ARTS loyalty program entities. In previous versions of the model there was no explicit way to represent subscription programs that customers pay for. Loyalty programs are typically free requiring only that customers register and grant permission to use their information to generate special deals and discounts. This revised, more general treatment of customer membership allows both fee/subscription based membership and free loyalty membership programs to be fairly represented. The ARTS model incorporates the notion of membership ranks which may involve different fee levels and associated different levels of benefits. The intent of membership levels is to represent relative purchased membership value. The model also incorporates the notion of earned reward tiers which allows a retailer to represent different benefit levels based on customer net purchase value. Unlike the membership level, the earned reward tier is based on customer actions not fee level. This approach provides retailers with a flexible, integrated way to reflect customer membership based demand development initiatives.
The model incorporates a separate RebateProgram. Rebate programs may be associated with customer membership programs. However, in some instances where a rebate is sponsored and paid for by an external entity, there may not be a membership requirement. By separating rebates from customer membership accounts, ARTS enables retailers flexibility to implement customer-linked rebate programs or separate, stand-alone rebate programs. A CustomerRebateAccount is typically require for deferred rebate rewards where the value of a rebate is tied to a cumulative measure of customer activity over a period of time.
Generalized Customer Account Ledger
Each CustomerAccount entity has CustomerAccountLedger entities to classify and accumulate monetary and statistical values for reporting and analysis. The modeling approach taken here treats each instance of a CustomerAccountLedger as a single reporting classification and cumulative value (or balance). This allows a retailer to customize the ledger account categories any way it chooses based on its business requirements. Customer ledgers may be very detailed or very coarse grained. This approach ensures a consistent way to represent a broad range of different customer ledger accounts. It also assigns CustomerAccountValuationUnitType which specifies the kind of currency or measurement units are used for a particular customer ledger account category.
Figure 13 - Generalized Customer Account Ledger
Sample Walk-through of Generalized Account Ledger Structure
The figure below presents a sample of how the Generalized Customer Account structure works. The key is its storing each CustomerLedgerReportingClassification for a given CustomerAccount as a row instead of as an attribute. This strategy along with the other entities for the valuation unit and account type provides a flexible, rigorous way to represent a variety of different kinds of customer account ledgers.
Figure 14 - Sample Entities and Values To Illustrate Generalized Customer Account Ledger
The enumerated values shown here for examples only. Retailers should define their own customer accounting metadata based on their business requirements.