2006 atlanta journal_constitution

21
1 Making A Good Database Better Presented by: Mark Klein Gwen Borders Atlanta Journal-Constitution MaaX Users Conference - March 27, 2006

description

 

Transcript of 2006 atlanta journal_constitution

Page 1: 2006 atlanta journal_constitution

1

Making A Good Database Better

Presented by:

Mark Klein

Gwen Borders

Atlanta Journal-Constitution

MaaX Users Conference - March 27, 2006

Page 2: 2006 atlanta journal_constitution

2

Our Delimma

Choose One:

“If it ain’t broke…. don’t fix it.”

Vs.

“Is that a light at the end of the tunnel, or am I about to

get hit by a locomotive?”

Page 3: 2006 atlanta journal_constitution

3

Topics

Where We Were

Situation

Re-design plans

Challenges

Where We’re Going

Circulation ROI

Multi-department usage

Page 4: 2006 atlanta journal_constitution

4

Situation – Original MaaX Context

Internal development team established Summer ’03

Astech selected for ambitious development assignment Spring ’04

Complex mix of 60 files, 10M records, four “master” reference tables

MaaX database launched in December ’04

Acculturation efforts through February ’05

“MaaX Lite” Vision: broad user community & simplified data views

In-house training program – 25 MaaX Lite “graduates”

Sales channel managers envisioned as campaign planners

Multi-department involvement beyond circulation

Migration to fully integrated sales processes using MaaX by Fall

Big promises for sales efficiencies & ROI

Where We Were

Page 5: 2006 atlanta journal_constitution

5

Situation – Realities Sink In

March through June: perspectives change….

New V. P.

New sales management

Slow cultural acceptance (low “risk” tolerance)

MaaX applications limited to direct response

Heavy dependence on “Virtual Fields”: over 100 in use

Proxy for business rules

Accommodate complex data/file combinations

Compensate for inherent MaaX software Query/Banding limits

Database stability and nightly processing/refresh over-burdened

IT uneasiness with channel integration capabilities

“Show me the money” ???

Where We Were

Page 6: 2006 atlanta journal_constitution

6

Situation – Gut Check

Can nightly refresh processes be shortened ?

Can the nightly refresh be error free?

Can we reduce dependence on Virtual Fields ?

Can we create effective business rules ?

Is there “head-room” for overall database growth ?

Can we “finish” the sales integration process ?

Telemarketing disposition data alone = 10 M records

Need multi-channel sales/retention choreography

Visibility across channels for individual household impact

BOTTOM LINE: DO WE HAVE THE RIGHT DATABASE DESIGN ?

Astech bravely posed this question…. thank goodness they did.

Where We Were

Page 7: 2006 atlanta journal_constitution

7

Redesign Action Plan – June/July

Define spectrum of sales & communication applications

All roads lead to a household… via many channels

Manage channel timing, sequence, and interval

Measure effectiveness of variations in these variables

Evaluate alternative database designs

Identify pros/cons of alternatives vs. existing design

Assess timeline and resource requirements

Maintain existing database functionality throughout

Where We Were

Page 8: 2006 atlanta journal_constitution

8

Re-design Challenges

Managing internal perspectives

Building current database usage - - broadening applications

Motivating core project team: “I thought we were done”

Limiting skepticism: “What’s wrong with design #1 ? Confidence in design #2 ?”

Providing tangible early ROI examples

“Push me – Pull you” relationship with Astech

Sharing Oracle/SQL knowledge and experiences

Acknowledging characteristics of SmartFocus software design

Anticipating (and revising) necessary business rules

Timeliness and mutual accountability

Compressing learning curves without sacrificing results

Where We Were

Page 9: 2006 atlanta journal_constitution

9 Where We Were

LADZ

AMST ACAM

CPTY CURG CSMC

DMCY

DMSF

DMMO

DMSI

DMLD

DMHI

ECAM

EDSP

2 1

SAMA SABL SAM3 SUB3 SUBA

SBIL SCMP

SMEM SDOL SPRM

SQUE SSTP

3

RLGC

1 – DM ADDR KEY

2 – BLOCK GROUP

3 – SUB ACCT NO

4 - PHONE

5 – SUB RRN

6 - AC / EX

SEML

1

5

7 – BATCH NO COMB

7

8 – ED ZONE

8

PMST

4

SDAE SDEE FIPS

SDEL

SMAS

SM3S

9 – SAM3 ID

9

SB3S SBAS

1 1

1

1 1

1

1

10 – AJC SAM ID

10

10

10

3 3

1 1

11– FIPS ST / CTY

11

PDPE

PNPA

PDNC PCAM PDSP PLST

4

6

Page 10: 2006 atlanta journal_constitution

10

Existing Design Challenges

No direct link between address, phone and email masters

Inability to include phones or emails where an address didn’t exist

Nightly Build Errors Increased Build Times

Virtual Fields dependency on other Virtual Fields

Query complexity Transactional Data

Duplicity Issues

Determining the most accurate information when multiple subscriptions existed

Table Volumes Maax screen limits

User Confusion

Where We Were

Page 11: 2006 atlanta journal_constitution

11

Making The Conversion

Accepting the final database design solution Is this the best approach to linking multi master tables?

Does this give us full integration?

Is the end users life simplified?

Preparing for conversion Identify and develop required Business Rules

Determine ways to merge data to simplify end user view

Testing and quality checks Business Rule validation

Processing Speeds

Parallel use Converting existing processes to new format

Testing old design versus new design

Where We Were ….Where We’re Going…

Page 12: 2006 atlanta journal_constitution

12

New MaaX At Work

Advantages of new design…. Master Tables that contain all records (with or without addresses)

Address Master ( 3.1 M )

Phone Master ( 22.7 M )

Email Master ( 2 M )

Direct Links between all master files thru business rules

Business Rules / Views

Determine best guess information for each master file

Use of multiple tables to determine Business Rule results

Creation of new fields from transactional data

Merging tables (send 60 files, produce 25 tables)

Reduction in Maax Table views based on security

Required fields for Campaign selection reside in one table

Where We’re Going…

Page 13: 2006 atlanta journal_constitution

13 Where We’re Going…

Database Design – Group 1

AMST

one-to-many

1 – ADDR KEY

2 – PHONE NUMBER

1 1

3 – EMAIL ADDRESS

ACAM

SUBA

CPTY

DMSF

PCAM

PDSP

PMST

SUB3

SB3S

SAMA

SDAE

SMAS

SAM3

SABL

PDNC

4 – fields pulled onto AMST

through business rules

SBAS

PNPA

PLST

5 – fields pulled onto

PHONE through business

rules

hidden table

MAAX view

PDPE

5

PMSF 2

EMST

SEML

SDEE

CURG

DMLD

DMMO

DMHI

DMCY

one-to-one (fields on

parent table)

6 – fields pulled onto SUBA

SM3S

OLQ

DMSI

DMLS

4

7

7 – fields pulled onto SUBA

through business rules

CSMC

LTRK

LINA

SSTP

FIPS LSR3

LSRA

EMSF

LPRF LPRM

SPRM

SMEM

SCMP

SBIL

SDOL

SQUE

LADZ

LCPA

1

LDOL

LQUE

ECAM

3

OCAM SCAM

EDSP

ADSP

PCHK

PDPEA

8 – File Merged with PDPE

8

OMKT 6

Page 14: 2006 atlanta journal_constitution

14 Where We’re Going…

Database Design – Group 2

AMST

one-to-many

1 – ADDR KEY

2 – PHONE NUMBER

1 1

3 – EMAIL ADDRESS

ACAM

SUBA

CPTY

DMSF

PCAM

PDSP

PMST

SUB3

SB3S

SAMA

SDAE

SMAS

SAM3

SABL

PDNC

4 – fields pulled onto AMST

through business rules

SBAS

PNPA

PLST

5 – fields pulled onto

PHONE through business

rules

hidden table

MAAX view

PDPE

5

PMSF 2

EMST

SEML

SDEE

CURG

DMLD

DMMO

DMHI

DMCY

one-to-one (fields on

parent table)

6 – fields pulled onto SUBA

SM3S

OLQ

DMSI

DMLS

4

7

7 – fields pulled onto SUBA

through business rules

CSMC

LTRK

LINA

SSTP

FIPS LSR3

LSRA

EMSF

LPRF LPRM

SPRM

SMEM

SCMP

SBIL

SDOL

SQUE

LADZ

LCPA

1

LDOL

LQUE

ECAM

3

OCAM SCAM

EDSP

ADSP

PCHK

PDPEA

8 – File Merged with PDPE

8

OMKT 6

Page 15: 2006 atlanta journal_constitution

15 Where We’re Going…

Database Design – Group 3

AMST

one-to-many

1 – ADDR KEY

2 – PHONE NUMBER

1 1

3 – EMAIL ADDRESS

ACAM

SUBA

CPTY

DMSF

PCAM

PDSP

PMST

SUB3

SB3S

SAMA

SDAE

SMAS

SAM3

SABL

PDNC

4 – fields pulled onto AMST

through business rules

SBAS

PNPA

PLST

5 – fields pulled onto

PHONE through business

rules

hidden table

MAAX view

PDPE

5

PMSF 2

EMST

SEML

SDEE

CURG

DMLD

DMMO

DMHI

DMCY

one-to-one (fields on

parent table)

6 – fields pulled onto SUBA

SM3S

OLQ

DMSI

DMLS

4

7

7 – fields pulled onto SUBA

through business rules

CSMC

LTRK

LINA

SSTP

FIPS LSR3

LSRA

EMSF

LPRF LPRM

SPRM

SMEM

SCMP

SBIL

SDOL

SQUE

LADZ

LCPA

1

LDOL

LQUE

ECAM

3

OCAM SCAM

EDSP

ADSP

PCHK

PDPEA

8 – File Merged with PDPE

8

OMKT 6

Page 16: 2006 atlanta journal_constitution

16

New MaaX At Work

Where We’re Going…

Page 17: 2006 atlanta journal_constitution

17

New MaaX At Work

Re-introducing New MaaX internally

Applying business rules in circulation sales/retention today

Best Guess Subscriber, Address, Phone and Email

Reduce many to one confusion

Target segment with multiple channels

Prior Transaction History Counts/Totals

Subscriber Data (ie: vacation donation, payment, complaints, etc)

Disposition Data (calling, contact, time of day)

Preserving relevant history

Business Rules links look at data age

Purging of incremental data

Where We’re Going…

Page 18: 2006 atlanta journal_constitution

18

Circulation ROI Opportunities

Measurable ROI contributions in 2005 Converting direct mail to 3rd class

Improving creative/response rates

Targeting subscribers for ad awareness survey

Providing cross-section of subscribers for market survey

Unsuccessful ROI attempts Targeting door-to-door crew sales

Direct mail as last channel

Targeting lifestyle clusters

Intangible ROI Contributions Do Not Call dialing history

Distribution route planning

Product development/geographic targeting

Where We’re Going…

Page 19: 2006 atlanta journal_constitution

19

Circulation ROI Opportunities

Active initiatives in 2006

Telemarketing by daypart (last connection)

E-mail supplementing direct mail

Multi-cell direct mail creative tests

Alternate pricing/offer terms

Targeting billed start programs by market segment

Planned initiatives in 2006

Integrated sales across multiple channels

Direct mail driving kiosk traffic

Subscriber value model and segmented loyalty program

Value-building messaging

Bundling opportunities

Alternative retention touch-point timing

Where We’re Going…

Page 20: 2006 atlanta journal_constitution

20

Multi-department Usage

Expanded MaaX usage desired, but slow to emerge…

Market Research: segmentation modeling for the market at large

Advertising: consultative selling/client target delivery

Product Development: aligning market segments with content and distribution

opportunities

Distribution: route-level inserting capability and overall route structure

Broader acceptance likely requires dramatic cultural shifts

Consolidated analytical resources (not silos)

Comprehensive view of analytical tools

Fully integrated databases and ubiquitous access

Tangible business successes will accelerate expanded use

Where We’re Going…

Page 21: 2006 atlanta journal_constitution

21

Discussion/Questions

“Be curious always. For knowledge will not acquire you.

You must acquire it”.

-- Sudie Back