Re: [AGA-mcm] Fwd: Re: What's cookin in Indiana

[Larry Lampert <l_lampert@yahoo.com>]

I think the information would be interesting although
I am not certain we will be able to draw many firm
conclusions based on any type of multi-buyer
regression analysis thang that we might construct.
There are a large number of reasons people join don't
join, renew after a year or don't, etc. 

I am not certain how much we can influence that buy
decision other than to continue to improve our
"product" as we have obviously done in the last few
years, i.e. color tag, AGA convention, AGA member
list, etc. That being said it would be good
information to at least look at provided it is not to
much work to compile.

However, I would like to do some data cleansing to our
master list. Since this is what I do for a living sort
of(I actually sell data quality software) I should be
able to this for us for ideally no cost. 

The first thing I would do would be NCOA-Link the
file. This standardizes (CASS)the addresses and then
checks for moves against the USPS database which goes
back 48 months. I would also like to do a deceased
removal (removes people who have died) but I am not
sure that I can do this no charge since the databases
have usage (Royalties) fees.

None of these are critical for us but either NCOA-Link
or some other type of move update is required by the
USPS for first class mail (every 6 months). Our mailer
is likely doing something like this on the back end
somewhere. The real value is to do it on the front end
so that the datawarehouse or list is constantly
updated.

Anyways this is a bit off topic but we could certainly
discuss it and see if it is worth moving on at some
point.

Regards,

Larry
--- "S. Hieber" <shieber@yahoo.com> wrote:

> 
> Well, I'm just a horse's back-end when it comes to
> database
> front ends :-\ . I'm not that kind of analyst. I do
> understand that our memberlist was made for very
> diff
> purposes and most of the history is not there. Then
> again,
> maybe 3 or 4 year old history is no longer ripe for
> analysis.
> 
> I knew we have some info for the active members, but
> I'm
> thinking of active status as just one attribute of a
> joiner.
> 
> Could be that the preponderance of members have
> tenures of
> 3 years but the active list comprises mostly 1-yr
> subscriptions.  We might have more core than
> rollover and
> lowering 1yr membeships will bring in more
> membership 
> years than the discount on 3-yr membership. Or we
> might
> have very few renews beyond, say, 2 years. We might
> then
> restructure the membership packages to entice more
> of these
> folks into an a 3rd year. Or we might have very few
> renews
> beyond a first renew -- in which case, we might want
> to
> focus on making the 3-yr memberships more
> attractive. This
> info ordinarily can't be gotten from an
> active-member/subscription list. 
> 
> I think this stuff is interesting but I can't put a
> value
> on it's usefulness.
> 
> If at some point we can pull out stuff like this,
> I'd like
> to go over it with Larry (and whoever else is
> willing) and
> see if any marketing conclusions can be drawn.
> 
> sh
> 
> --- Erik Olson <erik@thekrib.com> wrote:
> 
> > On Tue, 28 Jun 2005, S. Hieber wrote:
> > 
> > > Don't mistake me. I wasn't criticizing the
> components,
> > and
> > > I was using "database" in a loose vernacular,
> like
> > "info
> > > system" "computer info thing.". If I say I would
> like
> > to
> > > see the sedan in blue, it doesn't mean I think
> the red
> > one
> > > was not designed satisfactorily.
> > 
> > Actually it was an ugly shade of baby-poo yellow
> before
> > and now it's 
> > silvery-white-ish.
> > 
> > > Last time we discussed this sort of thing, I
> came away
> > with
> > > the impression that info was recorded for diff
> purposes
> > > than what I was fishing for -- tenure, rollover,
> maybe
> > some
> > > geographics if not demographics.
> > 
> > Primary purpose is for generation of the mailing
> labels.
> > 
> > But in addition, I added some fields that are set
> by the
> > label-generating 
> > script, so that we know exactly when inactive
> members are
> > inactivated 
> > (rounded to nearest quarter).  And we also have a
> field
> > for "First Joined" 
> > that gets set when the record is first added.  So
> from
> > this we can 
> > directly get stats like "For all inactive members,
> how
> > long between when 
> > they joined and when they were inactivated", and
> "For all
> > active members, 
> > how long since they first joined?".  Neither
> calculation
> > takes into 
> > account things like members who join, then lapse,
> then
> > get re-activated. 
> > But still, it can be used.  And it's easy to
> generate
> > (like I'll probably 
> > make a graph today).
> > 
> > In addition to the addition, since I took over the
> > technical management of 
> > the database, we also have a complete record of
> every
> > mailing "label" 
> > generated for each TAG (so far about 2.5 years). 
> So it's
> > THEORETICALLY 
> > possible to reconstruct a more accurate picture of
> member
> > behavior by 
> > correlating the same member from issue to issue
> (but a
> > lot harder to do 
> > than the other).
> > 
> > > Basically, what I envision is a list of everyone
> that
> > has
> > > joined AGA and their name never comes off the
> list --
> > it's
> > > a lasting universal truth that they joined AGA
> at some
> > time
> > > or other.
> > 
> > This we have.
> > 
> > 
> > > For each name there is a list of the months that
> > > they have been members, regardless of whether
> the
> > months
> > > are consecutive.
> > 
> > This we "sort-of have", in that we have the
> mailing label
> > records starting 
> > March 2003.
> > 
> > > This seems to me a diff thing than a list
> > > of current members and how long they have signed
> up
> > for,
> > > which is what I thought the current info system
> > recorded --
> > 
> > Nope, that's NOT what we do.  We definitely do
> more than
> > that.  The 
> > database is probably closer to what you're
> envisioning
> > than what we do.
> > 
> > And actually, if you really think this is
> important, it's
> > trivial for me 
> > to add another field called "Cumulative Issues
> Mailed"
> > that gets bumped 
> > by the script every time we generate a mailing
> label list
> > (as we've 
> > already got the logic that decrements the "Issues
> > Remaining" field and 
> > inactivates non-life members when it hits zero). 
> I can
> > probably even rig 
> > something to backfill the last 2.5 years of
> mailing
> > labels into it.  Hmm.. 
> > just need to have some really boring long meetings
> to do
> > this during...
> > 
> > > I'm not complaining the red is a bad color of
> sedan,
> > just
> > > that personally, I'd like to see something in a
> blue.
> > But
> > > I'll be the first to admit that I don't know
> diddly do
> > > about info systems. And I have no idea how much
> work is
> 
=== message truncated ===

_______________________________________________
AGA-mcm mailing list
AGA-mcm@thekrib.com
http://lists.thekrib.com/mailman/listinfo/aga-mcm