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

["S. Hieber" <shieber@yahoo.com>]

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
> > involved or whether it's worth the effort jsut to
> distill a
> > few "facts."
> 
> Well, again, remember that there are two parts here --
> the database itself 
> which is just a bunch of files of data -- and the
> front-end WEB UI and 
> scripts, which are where the real art comes into play.
> 
>    - Erik
> 
> -- 
> Erik Olson
> erik at thekrib dot com
> _______________________________________________
> AGA-mcm mailing list
> AGA-mcm@thekrib.com
> http://lists.thekrib.com/mailman/listinfo/aga-mcm
> 

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