	Vibrant Life Plans	Electronic Information System Plan	Data	Admin Scale For Vibrant Life
New Theme Page	Policies	Programs	Notes	Table Of Contents
	New Database	eCourses	Quizzes	Search

FAX Newsletter Establishment Program

August 28, 2004
Revised On May 23, 2012 4:50 PM

This Program can best be viewed by looking at the initial publication on the web of its structure and purpose, as follows:

Home Web Page For Karl Loren's Weekly FAX Newsletter

Top

Full Explanation of this page BELOW -- Click

Return To Top

Reference	Subject


Vol. 1, No. 1	High cholesterol is NOT a risk factor for heart disease and stroke. This is one of the biggest myths in health care. A complete report on this at this link.

Return To Top

Explanation Of This Page

Return To Top

Karl Loren publishes a newsletter sent by FAX to any who subscribe. That newsletter is published approximately once per week. This newsletter is sent by FAX only, with an automatic broadcast to occur during the evening hours. It is ONLY sent regularly to those who ask for it. However, Karl does use an unsolicited FAX broadcast to acquaint people with the availability of this newsletter.

The only regular subscriptions accepted must be made by sending a request on the FAX number which is to be added to the subscription list. There is no cost for this Newsletter. Karl has been publishing his newsletters for many years, by mail, FAX and eMail.

Your FAX number will never be given to any other person -- it will be used ONLY to send out this FAX newsletter.

It features a single page format. The page always includes information about how to remove the FAX number from the subscription list.

The main content of this single page newsletter usually will consist of a very brief description, generally of only two or three sentences, of a topic that might be of interest to you. Occasionally there might be two or even three different subjects -- but always one page.

Because a FAX does not offer a method of "clicking on a link" the FAX newsletter does not include a web link, but all the details of the information related to the newsletter is contained on one or more of the 100,000 pages on 30 different web sites published by Karl Loren. Karl continues to publish new pages.

There is only ONE link/address shown on the newsletter -- to this exact page. www.karlloren.com/fax/

So, for any issue of any of the newsletters, you would come to THIS page on the internet and THERE you will find the link that takes you to the specific information on one of Karl's other pages -- to the page referenced in the FAX letter. The most recent newsletter is always the top listed item on this page.

Once you have bookmarked this specific page, or just remember it, or note it on the FAX newsletter, you can always find whatever it is that is the featured subject of the FAX newsletter on this same page.

So, just keep in mind http://www.karlloren.com/fax/ and you will always find THIS page at that address.

Every week Karl adds a new link-reference to this web page -- whatever was featured on the FAX letter for that week.

This page, also, includes all the past links so that at any time you can return to this page and find the link for some previous FAX letter. When the list of links becomes "too long" they will be archived off to a separate page -- never lost for review.

Anyone who wishes may go to any of Karl's articles, download and print for personal distribution. The only request Karl makes is that the contents are not changed and Karl's name and address remain associated with the material. This way someone who receives this Newsletter by FAX can copy/print the newsletter to give to others who may not have computer access.

Karl invites personal FAX messages to his FAX number and will generally respond to them personally and promptly.

Return To Top

The only way a person can get on this regular FAX subscription list is to request it with a FAX message to Karl's FAX number.

There are simple security measures possible with eMail to be sure that the person who subscribes to an eMail Newsletter really wants that Newsletter.

Such is not feasible with a FAX newsletter.

Karl accepts new subscription requests for this FAX newsletter when they are sent to Karl's FAX number FROM the FAX number which is to be added to the subscription list. For these same security reasons Karl does not accept a subscription request that comes by phone, eMail or letter.

There is no further verification of whether this was a legitimate subscription request.

FAX machines are commonly available to dozens of people in one office -- any one of them could make a FAX request for the subscription. The FAXed newsletter might then arrive contrary to some Company Policy on such. In the past this did not happen, but it could.

Karl will remove a FAX number from the subscription list upon receiving any FAX message from that FAX number -- no further verification is made by Karl as to whether this "un-subscribe" request is genuine.

If you have been added to this list by some error, a simple FAX request will get your number removed. Likewise, if your FAX number is removed in error, a simple FAX request will put you back on the list.

You never have to worry about "missing" a newsletter since they are all referenced on this exact page.

If there is some better way that is practical to protect your privacy, Karl will implement that.

Return To Top

The above is actually on the web at www.karlloren.com/fax/

The above functions on THIS page exactly as it does on the web page.

The concept is:

A subscription to a FAX number is entered
A Fax is sent out, probably weekly.
The Fax gives the short description of the "news"
The Fax reminds the reader that the actual data is on the web
The Fax reminds the reader that the actual data is available from a web page link
The Fax reminds the reader that the link is always on the same page on the web
The web page reminds the reader that he can send a personal FAX message, and get an answer
The web page provides a link to all previous news items, with the most recent on the top of a list.
News items to be used in future Faxes are "stored" on the web also, not accessible unless you happen to have the address design: p1.htm, p2.htm, p3.htm, etc., for the future issues, and v1n1.htm, v1n2.htm, v1n3.htm, etc, for the items that have actually been published so far
When needed, a separate folder for archives of news items
There must be a cookie installed on all visitors to this page -- logging their continued activity on any of our webs, including all pages visited and shopping cart visits and purchases
Initially the subjects of these news letters may be mixed, but one future plan could be to create new Fax Newsletters, on more specialized subjects -- a "heart disease FAX" and a "cancer FAX" etc.
Eventually, with 100,000 pages to choose from, this program should be able to be taken over by someone else, but initially it will remain a pilot program, Div 7, handled by Karl

Loren Wm. operates a service of bulk FAX broadcasting. He has given me the figure of $0.03 each delivered FAX for 10,000 sent at one time. I expect to select some appropriate classification of businesses (with FAX numbers) and try the same list for three uses -- to test the validity of this method of promoting the FAX newsletter.

That would mean about $900 for the cost of 10,000 FAXes sent out three separate times.

In the "old days" it would seem worth it if I could obtain the name of one interested person if the cost of that one name was $5.00 or less. This is just a guess, based on old standards. At $5 per name that would mean that about one subscriber out of 150 FAXes sent would probably be viable for this technique.

If 10% of these people buy something within the first year on the subscription list, that would mean a cost of 10 subscribers, per week of $0.03, for 52 weeks, or about $50 for the names and $15 for the weekly FAXing cost to the 10 numbers for one year. This totals about $65 per customer. At our desired profit rate this would mean we would need to sell the one person, out of 10 subscribers, would have to purchase about $150 worth of products in the first year to cover the cost of acquiring all the names that allowed ONE buying customer.

Some analysis like the above is vital in reviewing the viability of this program. The viability of the program must be reviewed and it is just as important to be able to collect the statistics that allow this review as it is to do the program in the first place.

I will also feature the above web page, or some similar page, on one of my next electronic newsletters -- that has some 15,000 subscribers. The cost of sending the message to these 15,000 people is negligible so I won't figure a further cost to acquire one customer from this source.

If we send out 10,000 FAXes, three weeks in a row, we could expect to get about 666 subscribers. That would seem to be an acceptable result -- and worth increasing the number of promotional FAXes sent out -- it would take some months to see if they then also turn into buying customers.

There should be an increasing number of new subscriptions because of "word of mouth" from the existing subscribers -- basically a "free name" added to our list.

Taking $0.05 for the weekly cost of sending out to the actual subscribers, each subscriber would cost us about $25 per year in FAX costs. I am using $0.05 rather than $0.03 because the lower figure was for 10,000 Faxes. I presume there is a higher per-fax cost for a lower number of Faxes.

There may need to be some further analysis of this, and some further methods of measuring success, other than just a sale.

We have to accept that one FAX subscription may well be seen by many people in one office, so it becomes very important to "capture" the "prospects" when the visit the one central page:

www.karlloren.com/fax/

It could well be that many different prospects would visit that page from ONE FAX subscription.

Cookies are the key to success in this Program.

I have to get this fully implemented, and mostly it is Gordon doing this part.

Presumably every visitor to any page on any of our webs should automatically get a simple cookie that identifies "him" as a visitor" without getting any personal information. That one cookie allows all future visits to be tracked, including when and as the person goes to one of the pages where "registration" takes place and there is either a new cookie, or the first cookie is expanded in use to include whatever information was provided in the registration process.

Even with the simple cookie, even not knowing the person's name, the cookie should allow us to vary the content of ANY page to take into account all previous web-visiting activity by that person.

This is the magic of cookies and calls for tremendous design work by Gordon, not just the design of the cookies, but more importantly design of the system which will keep track (log) all of this activity (thousands of persons every day) and bring up for review whatever type of activity we decide would be worthy of designing some special "page content" for that person when he next visits.

This last is the modern miracle of web experience which I believe can greatly multiply our sales and expansion -- much of this lies in the area of the programming of such a system -- the other important part lies in the area of conceiving what changes in page content will be presented to the person, based on the log analysis presented by the system.

To give Gordon a target here, consider that it may seem difficult to measure the contribution of a "programmer" but I think we can.

The present collection of some 25 webs, 100,000 pages, provides for none of this cookie use or tracking. Our current weekly sales range from $8,000 to $15,000 with a few higher or lower than that range.

When and as we can point to sales of $50,000 per week, about a 5X increase, and feel reasonably that it is the WEB Cookie Tracking System that is the major cause, I think we can conclude that Gordon did it -- assuming he is the guy who majorly does the programming that allows this all to occur. I think this could occur within 12 months of a reasonably intense period of programming and web innovation and modernization.

The future work on this project includes the possibility of installing a cookie on the above page to track visitors and see how many click through to the existing link, or any further links.

I will be adding my new FAX number as soon as it is installed.

Gordon will be providing any bright ideas he can to enhance this promotional tool, as will Maia and Tracye.

Dear Gordon,

I've written a comment about cookies here:

http://www.lucid-minds.com/Plan/Data/p69.htm#b

user:

PW:

Which I would appreciate your reviewing for the accuracy of my understanding.

I recently designed TWO promotional programs for VL -- one I wrote you about -- to send out 10,000 bulk FAXes, promoting a FAX newsletter. My son provides this bulk FAX service to public clients.

The other, I didn't describe to you, was to arrange for the purchase of 10,000 names and have a post-card bulk mailing to that list.

Both programs have the purpose of attracting "new names" into the VL realm, and as prospective customers.

The FAX cost is $0.03 each, compared to the bulk mail cost of about $0.30 each -- about ten times more costly to send a bulk mail postcard as to send a bulk FAX. The bulk mail would have the further cost of responding with the cost of postage and literature -- this makes bulk mail far more expensive than a FAX/Web - based program, if the FAX program "works."

When and as this is better known the FAX business will greatly increase. My son has a rapidly expanding business with bulk FAXes -- people are finding them effective.

Of course, there are still rumbles about bulk FAXing being unwanted, like spam eMail, but so far this rumble is not too serious.

If my FAX project produces results even of 1/10 the the result of the bulk mail, it would be cost-effective.

I suspect that the results would be closer to equal.

thus, the future promotion should and would greatly emphasize FAX broadcasting over bulk mailing. To increase a bulk FAX program from 10,000 fax numbers to 100,000 fax numbers can be done in a couple minutes -- to increase a bulk-mailing of a postcard from 10,000 to 100,000 brings all sorts of delays and new decisions on the type of list and even the time needed to schedule printing and mailing.

In either case the capturing of statistics on results is vital -- without those statistics the promotion is virtually worthless whether by mail or FAX.

Also, if the FAX leads to a web experience rather than a phone call or other lower-level type response, then the FAX/Web promotion will have a gigantic application for as long as too many people have not heard of it and started to use it.

My system becomes relatively automatic when a cookie is included in the mix.

The key to statistics on bulk mail is to couch the language of the mail to include a "code" or something that makes it easy to identify the person when he calls or writes to respond.

The key to continued use of FAX broadcasting will certainly be to use a targeted web page as one of the means of capturing the results, and that seems to me to absolutely require a cookie to be installed on all those FAX recipients who visit that page, and subsequently visit other pages, or who buy -- without that cookie we have no way of measuring the results of the FAX promotion.

(I could personally install a "counter" on that page and that would give us a very crude statistic, but nothing about future purchases by those who visited that page or even any stat on the click-throughs from that page to the featured item elsewhere on my webs.)

I am keen on getting that cookie installation in place -- not only the installation upon visiting that one page www.karlloren.com/fax/index.htm but also some means of detecting every visit to any of my 100,000 pages by any browser with the cookie, and then storage of the log files that would be generated for each cookie-equipped browser -- whether we have the full system for analyzing that information ready or not. At least we should be able to get some rudimentary information from this cookie and the database it would be connected to -- not so?

You once mentioned that you have a way of working with such cookies across all our URLs, not just one -- if that cannot be implemented immediately, it would be enough to start with that detection taking place at the shopping cart entry page.

While the shopping cart is vital to us, also, the use of a cookie on the shopping cart is a vital part of its final utilization.

I would like you to take some time off the details of the shopping cart to finalize the aspects of the cookie usage (for the shopping cart) which would seem to me to be just as applicable the way I have described it here.

In other words, place a cookie installation script at www.karlloren.com/fax/index.htm and create the beginning of a database entry for that cookie ID, and for all subsequent (log) data that can be automatically gathered, even without the person registering or giving us any personal information. Probably that cookie installation script would be the very same that you did for the LMS and for the new shopping cart.

The cookie installation STARTS a record in a table in our database -- the table can have hundreds of fields that are not yet used (name, address, etc.) and other hundreds of fields for log files of page visits.

If this works, this one program could result in a very large percentage increase in our business, very quickly, at relatively low cost.

The key to this is a "web page target" for the FAX, and a cookie installation on that page plus some system of storing the cookie information, log files, related to that cookie. If you can store the information, you must also be able to analyze it.

This would probably be a shift in direction for you -0-- but, it seems to me to be something you would be doing eventually anyway. The shopping cart will be a great improvement for us, but the immediate use of the cookie, as I describe it, could increase sales next week.

As I understand it all, the first cookie that is installed is the only cookie ever needed. We don't have to "warn" people that the cookie is being installed -- we can "inform" them that the cookie is in use when they register (name, etc.) but I don't feel that information is needed for the visitor before registration -- it is just too common on the web.

Cookies, eventually, would be installed ANY time the person visits ANY page within our group for a first visit -- that would call for a "system wide" cookie installation -- but this FAX page is of particular interest right now.

Comments?

Regards,

Karl Loren

My goodness, Gordon!!

I just spent some minutes composing my message to you about cookies, before reading this -- this is prophetic.

You are coming dangerously close to proving you are worth a full time salary!!!!

From: Gordon Bateson [mailto:gordon@kanazawa-gu.ac.jp]
Sent: Wednesday, September 01, 2004 4:12 AM
To: Karl Loren
Subject: site-wide cookies

Dear Karl,

thanks for your emails today and for your patience.

You may remember that in July I research into tracking possibilities and decided that "phpopentracker" provided the best and most detailed and instantaneous results on where a visitor had been. It is installed and waiting to serve. In order to run the following lines of code need to be added to EVERY html file that is to be tracked:

Karl: I can install this code on the www.karlloren.com/fax/index.htm page immediately, but will await your reply before doing that. I can certainly do this.

They need to be added just before the final </BODY> tag. I found an Apache module, called mod_layout, that would add these lines automagically to every document that was served up. It too is installed, tested and ready to run if switched on. However, as we discovered, it clashes with the Front Page Extensions (the FP forms stop working), so for the time being, it is switched off.

Two solutions occurred to me: first, we could stop using Front Page Extensions, and so switch on mod_layout again. The alternative is to find some other way to add the lines to EACH and EERY file on the server. I could write a PHP script to do it, but I believe I would do better to do it the Microsoft way and so I will wait till I get my copy of FrontPage 2003 next week. I am sure it has a way to add standard headers and footers to all files in a site. That is my plan at the moment.

Gordon. This is exciting. Could I say that "great minds in parallel think?" or some such trite saying.

Front Page allows certain proprietary features to work only because of the Extensions on the server. When those features are identified, I'll bet I don't use many of them -- and that there will be a PHP alternative -- for instance the message form that I now use on every web -- perhaps 50 instances of those -- they could all be replaced relatively easily by a form not requiring FP Extensions -- also, as I've mentioned, Front Page allows for publishing into webs that don't have the Extensions and allows that publishing by more than just FTP -- so I could continue to use FP with which I am so familiar, but we can easily remove the FP Extensions from the server and start using one of the alternative means of publishing -- even from FP.

This all sounds like a large break-through of good news.

I'll await your response before I install the cookie script on the FAX page, but it sounds like we are ready to move ahead with the FAX promotion very soon.

The above script mentions one URL, www.vibrantlifenames.com I assume that the same script will work on any page (even outside our realm) and the detection would be from any of our pages (in our realm) when you turn on the Apache module??

Great!

best regards

Gordon

More . . .

Karl

Dear Gordon,

The FAX page is being promoted by a real FAX, 10,000 of them sent out to a bulk list of FAX numbers. These arrive in offices all over the US -- probably many will be thrown away quickly -- like spam eMail, but some number will be read, and often by more than one person at the office.

That FAX gives the address:

http://www.karlloren.com/fax/

that is, of course, a folder only, but the "index.htm" is there and opened by default and leaving it out of the reference simplifies the FAX message.

When this campaign is done weekly, the address will ALWAYS be the same -- there is a list of links on that page with the current link being on the top of the list. A new link is added every week, and that is the link featured in that week's FAX.

That is the ONLY page I am interested in putting the cookie on just now.

I don't expect anyone to find this page except because of the FAX promotion.

I won't be referring to that page from any other web page.

So, someone gets the FAX, sees it, hears about it, and gets on his computer to go to THAT page. he gets the cookie. From that web page he clicks on the link to the main content page. The main content page will always be a link. This is a "portal" page.

So, just one cookie for now -- on the "portal page" for the FAX promotion.

After that cookie is installed the next question is, where on the web is the cookie then detected?

I don't know what you have planned on that. Likewise, when the cookie is detected, what record is made of that detection.

I assume that this detection could be made to be "server-wide." That is, any web page anywhere among the 100,000 pages would be within the same server and could be detected by some universal server detection system. (If not, then start detecting only when he arrives at the shopping cart -- presumably the first (entry) page of the shopping cart).

What I suggested a few days ago was a very large project -- not all necessary to start, and that was that the "cookie detection system" (wherever it is located ??) detects the cookie and then creates a TABLE in a group of tables -- one table for every cookie. There could eventually be many thousands of these tables!

The records in this table consist of the log files for the browser with that cookie.

I understand our server creates a "log file event" for every click on every page -- that is where the Urchin information comes from.

I don't know all the stuff that is in a log file, and perhaps only some of the items out of the log file need to be placed in that record --- or, it may be easier to have the record just contain ONE field -- being the entire log file -- which would be a very long horizontal line of text, I believe -- text that could be parsed later to pull out of it whatever we want.

OR, the detection system could detect the browser with the cookie, grab the log file and parse out of that file just several of the items in that log file and put them in separate fields in that record.

(I believe the log file includes a record of every separate image which is called when one page loads -- the capturing and storing of data about images would certainly not be worth keeping.)

Certainly the unique identifier in the cookie (I assume there is one) would be the "key" field in each record in the Table -- what else? Well, you could also capture the date/time, page visited, "entered from" (outside, for instance) (some other page, perhaps), "exit to page" and whatever else seems useful to store.

If we do not try to detect and capture log files for other pages, at least any time that browser enters the shopping cart that would be a very significant event -- want to capture that.

At some point the person "registers" and then a NEW table gets created for that person -- with the link to the cookie table, and with whatever other information we can gather from the person -- such as name, address, etc.

The cookie would stay the same after he registers -- or, there could be a changed cookie but the original unique identifier would remain the same -- now with additional data, identifying THIS browser as having registered. So, the system would locate the browser by the "userid" which could be part of the new cookie??

So, to answer your question again, I am after a statistic on how many people visit the "fax" page (assuming they all come from my promotional fax). Then, at the very least, how many of them buy something.

Out of 10,000 bulk FAXes sent out, a 2% response would be fair -- meaning about 200 people read the fax, become interested, get to a computer, enter the URL shown in the FAX, visit the FAX page, and get cookies. They either click on the link, or do not.

I am hopeful that about 10% of those 200 people will buy something within one year -- so the cookie should be "good for" one year.

If, in fact, 10 people (5% of the 200 people) buy something within 10 days, and the total purchases from these 10 people equal $1000, then we would be in a position to calculate the profit on that $1,000 and compare that profit with the cost of the FAX program (about $400 for the FAXing). Since we count on many repeat orders, once a person has bought once, we can safely assume he will buy again -- and we make more profit then without having had to pay for a FAX message to him.

Another way to look at it would be, "How long does it take for the flow out 10,000 FAXes to generate $1000 in purchases?" -- made a bit more complex by having a weekly flow of 10,000 FAXes (every week), so "How long would it take for this flow, going for three weeks, say, to generate $3,000 in sales?" -- thus probably validating the cost of the FAX campaign and allowing us to either increase the weekly FAX flow from 10,000 to 1,000,000 or go on for an indefinite number of weeks.

My son has 26,000,000 FAX numbers available -- and we can certainly send to the same FAX number several times -- since a FAX thrown away one day may be kept and read another day.

The statistic (result) of the FAX campaign must be measured or we would be promoting blind -- no way to manage.

I may have some fundamental misunderstanding of cookies -- if so, correct me soon.

A cookie will be ultimately useful almost ONLY if it is connected to a data base, and then only to the extent we are able to grab data out of the database into reports and as the criteria for "decisions" and "web page content changes."

Hope this does it. I'll be home, mostly working, all this long weekend.

Regards,

Karl

From: Gordon Bateson [mailto:gordon@kanazawa-gu.ac.jp]
Sent: Friday, September 03, 2004 5:25 PM
To: lct@oralchelation.com
Subject: Re: backup

Dear Karl,

I will make the cookies a priority. Where should we start? Which pages do you imagine people coming to from the campaign? Or do we want tracking on ALL pages from the out set?

regards
Gordon

----- Original Message -----

From: Karl Loren

To: 'Gordon Bateson'

Cc: tracye@karlloren.com ; Loren Wm. Troescher ; Tracye Bell

Sent: Saturday, September 04, 2004 1:11 AM

Subject: RE: backup

Dear Gordon,

That is now more clear.

There might be a way of using the DNS service to point to a newly configured path.

I think DNS and something "like" DNS for the "local paths" is part of the general Verio background service -- and that is what tells the server where to look for a particular file/folder.

The above is probably not accurate.

Go for it!

From: Gordon Bateson [mailto:gordon@kanazawa-gu.ac.jp]
Sent: Friday, September 03, 2004 5:16 AM
To: lct@oralchelation.com
Subject: Re: backup

Hello again,

sorry, my earlier response did not include an answer to this important question.

So, where are these "names" in use?

The "names" I was talking about are the "names" of the directories on the server which hold the webpages for a particular website. The server has a settings file, httpd.conf, which maps a given URL, for example "www.oralchelation.com", to the directory which holds the files for that website - "/www/vhosts/oralcom" in this example. Of course, if we change the name of the directory on the server, for example to "/www/vhosts/oralchelation.com", we have to change the settings file to point to the new directory. That's no problem. We will also have to change the settings on the programs we each use to upload and download to the directories. For "simple" FTP programs, there it is trivial, but I am worried that changing directory names will upset the FP and its extensions, so I don't want to charge in and change everything all at once.

Hope this is clear.

Out of interest more than necessity, I would like to know how the directories on your PC are set up and named. In particular, what is the path on your PC to for example the folder that holds the "oralchelation.com" site? On my machine it is:

D:\My Websites\vibrant life\vhosts\oralcom

I never see anything like "vhosts" in my path.

Mine would be like:  D:\My Documents\My Webs\kloren

or

D:\My Documents\My Webs\oralchelation

or

D:\My Documents\My Webs\oralchelationnet

The last item in the path never contains any " .com " extension and the names are shortcut names -- could be "blabla" and still work fine

These pages are published TO the standard URL, such as:

http://www.oralchelation.com

or

http://www.karlloren.com

I always publish TO an address with both "http " and "www."

But, if I want to download the web from the server I can use either:

www.karlloren.com

or

http://www.karlloren.com

I believe -- but not sure

That URL address is just like a browser address -- and it is "resolved" in the same fashion that any browser request for that page world be resolved -- that's where the config file comes in, I believe

Karl

I sure would like to see that cookie installed and some collection of data from the cookie, at least for the FAX page --

There is a vital management datum here:

"Production is senior to organization."

What you are doing is organizing web folders and paths -- even all the shopping cart work is organizing (for higher production).

Organization is what allows more and better production to occur -- so organization is needed.

But, production (sales) is always senior.

When production runs into obstacles from lack of organization, then your organization becomes vital for expansion.

Tracye is helping me very much tighten up our management here -- using statistics much more than I had -- sales were up two weeks ago -- OK. But, they were down last week, so there must be something done, now, now, to bring them up this week.

They are higher Thursday yesterday than Thursday last week, so that's good, but there has been a long-term downward trend that must be reversed.

Without getting into more details, the common denominator of "expansion" is "promotion" and that means "particles out" which lead to "particles in" (sales.)

The FAX newsletter will be a 10,000 FAXes sent out -- the outflow, the particles out that is needed for our production to recover a long-term trend of expansion. We are working on other types of promotion -- that is where all the attention needs to be when the sales are down.

Even organization -- "long term organization" would have to give way to "organization which will allow increased production today" is more important.

And, an outflow with no means of measuring the results is very poor management.

FAXes could nicely be sent about next Tuesday -- or Wednesday -- since Monday is a big holiday here FAX machines (mostly in offices) won't be active over the long weekend -- but by Wednesday that would be the day I want to send out the FAXes -- and need some sort of cookie detection and data capture -- even if ONLY the capture of data such as a FAX person (cookied) visits the shopping cart, with no further data yet captured other than the visit -- later, for sure, I will want to know what was purchased, etc.

  Karl

cheers!

Gordon

----- Original Message -----

From: Karl Loren

To: 'Gordon Bateson'

Cc: jason@oralchelation.com

Sent: Friday, September 03, 2004 2:00 PM

Subject: RE: backup

Dear Gordon,

Interesting that looking into the backroom shows that "my server" is 8.4 GB?? Is the difference mostly log files?   There is a need to delete old log files periodically -- I have done it in the past -- but not in some years.

Server Type: Managed Private Server
Domains Hosted on Account: 29

Disk Space Used:

64.95%

13000 MB total ; ~8444 MB in use

Bandwidth Use:

1.88%

200 GB total; ~3.75 GB used Bandwidth History

From: Gordon Bateson [mailto:gordon@kanazawa-gu.ac.jp]
Sent: Thursday, September 02, 2004 9:20 PM
To: lct@oralchelation.com
Subject: backup

Dear Karl,

I have finished compressing (15mins) downloading (4 hours) decompressing (45 mins) "chelationtherapyonline.com" and ALL its sub-webs (except log files). Altogether this data weighs in at 602 MB when compressed, and 1.39 GB when uncompressed. That's a lot webpages!

I have backed up the compressed file onto a CD. The decompressed files are on one my hard drive. I am experimenting with "site definitions" on Dreamweaver to see what is involved in renaming and restructuring the the folders of some of the sub-webs. I will start with the older, smaller sub-webs.

I assume you will take care of a distant web, such as www.oxygentimerelease.com on which there is a link such as www.karlloren.com/diet/sugar/bad/14.htm or some such -- if you eliminate the folders, "diet" and "sugar" and replace them? Then, obviously the link at oxygentimerelease.com would have to be changed??

Am I right in thinking that you and I are the ONLY people who upload and download things to sites? I need to be sure so that we get the timing right for changes to the folder structure.

You are right. No other person -- Jason has done a small bit with www.oralchelation.com -- working on the Google AdWord campaign, but I will ask him to stop on any of that unless he gets your/my permission before hand.

I would like to suggest the following naming conventions for the folders containing the sub-webs:

    - the name of the top level folder is the SAME AS THE PRIMARY URL for that site. The primary url for a site is the url that doesn't include the "www." For example, "academyanabiology.com" or "arthritisinformation.net". FYI, the secondary url for a site is the primary url prefixed by "www."

When you say "name" you mean the "name" on our local hard disk I assume. I do use various shortcut names -- but what I "call" that web for local use does not get published to the web -- but only the contents.

So, where are these "names" in use?

    - under the top level folder for a site, are several folders intended to be hidden from browsers of the site. These folders include "cgi-bin" and "logs" and perhaps some others. There will also be a folder called "htdocs" (HyperText Documents) which holds all the documents that are intended to be viewed directly by browsers of the site. In some cases this "htdocs" does not currently exist, so it will have toi be created.

A full list of the sites I am talking about is available here:

http://www.vibrantlifenames.com/karlsites.html

There are several other folders in the "vhosts" folder which are not on the above list. Many are empty. They look suitable for deletion, but I will contact you about those later.

all the best

Gordon

Tables Of Contents With Full Details: Page Title, Comment and Date Last Modified
Alphabetical List Of All Company Policies	Table Of Data in Title Order	Staff Assignments showing titles	Programs & Projects In Title Order	Table of Notes In Title Order
Policies In Order Of Last Modified	Data In Order of Last Modified	Staff Assignments showing date last modified	Programs & Projects In Order of Last Modified	Table of Notes In Order Date Last Modified