Currently, your web site is designed to the "average" common denominator. With your PR push, this is significantly lower than most of your long-time and paying users. As a result, you determine the most likely path for your users, set the cache bits and logic assumptions based on that, and don't test to see what happens if they don't stay on the path most of the time they are online. You need to use a true virtual presence that isn't reliant on the assumption that users are going to go down the path that you believe they will use. So, some suggestions:
SUGG 1: Cache to memory, not to disk.
From watching the message boards, the biggest issue appears to be a reliance on cached sticky bits (or whatever cute name you guys are calling it.) Especially if "clear your cache" really works. The cache reliance is amateurish, at best, aged and incompetent, at worst.
SUGG 2: Cache to one cookie of your own.
If you have to, cache to a single cookie, and give them a "reset" link to replace that cookie with virgin data, or clear it yourself when they leave the area they were in. And, before you listen to the developer, yes, they can do it, it just takes experienced programmers to get it right.
SUGG 3: Invest and trust your testers!!
No experienced / committed IT tester would every have supported the whole sticky bit cache thing you use. The person who believed the "new kid on the block" developers 5 years ago when they said it was the only way to do it, should have been (hopefully) replaced with someone more technically aware.
The cost to Ancestry of using that solution is the first support ticket requesting a solution to a strange problem; the second support ticket when it comes back; the irate posts on the message boards; the people who stop using the system to store their primary data, and just use it for searching; etc. And, the professional users who stop using ancestry.
The cost to your Member of wiping out the cache, is that it wipes out ALL their settings for all their OTHER programs that were working just fine. (Including "recognized device" settings, saved browser settings for other web "applications", etc.) And, back when passwords were cookie based, not password managed... they may even lose passwords for older less secure applications.
Please understand that this type of programming is the classic proof of whether or not an innovative solution can become a strong IT company. Strong developers don't make amateurish mistakes. Strong testers keep management from letting developers make amateurish mistakes. Strong IT management trusts testers over developers enough to do the research and impact analysis. Strong IT management is able to explain the costs / benefits to the "Marketing" side of the house so that they choose to make money, not spend it in customer relations management.
At some point, you're going to have to choose between credibility and short-term revenue, and clearly you already have, genealogically. However, TECHNOLOGICAL credibility still has value! As the other genealogical database services jump on the wagon - MSN/ Google/ Yahoo /etc. leveraged the "novice users" that AOL brought online - you need to stay ahead of them by *being* the easier to access, trouble-free solution to genealogical searching. The others are catching up, and some of their data is freely accessible. A good web-crawler search engine with a GUI could easily supplant you, and even be profitable without charging the users. (AOL vs. MSN)