in case anyone is curious, the following are the settings for that del.icio.us auto-posting for community server, for this blog:
| job_name | out_name | out_pass | out_url | out_time | out_blog_id | out_cat_id |
| [whatever] | [userid] | [password] | http://blogs.no-ip.org/blogs/del.icio.us.ashx | [0-23] | fractalnavel | 1040 |
i only mention this since it took some trial and error to figure out that "out_blog_id" was not the blog number (or "section id" in cs), and i didn't see anywhere where someone had posted that info. on the other hand, the "out_cat_id" is what it says it is.
still not convinced it makes sense to post these links to a weblog when they are already stored online in accessible formats. maybe if i was able to configure them not to be syndicated here... well, i could change the default for this blgo, but then i would have to remember to configure every other post to be syndicated when i create them. ugh.
having a bit of a dispute with a customer:
The licensing of the material from ProQuest is still at issue. I do not believe we can display them as has been done in the past, and certainly not as proposed for the future.
"... Downloading of all or parts of the Products in a systematic or regular manner so as to create a collection of materials comprising all or part of the Products is strictly prohibited whether or not such collection is in electronic or print form. ..."
(1)(f): (providing remote access)
"If your subscription allows you to provide remote access to the Products, you will limit access to the Products to Authorized Users ... The term “Authorized User” means: (1) For public libraries: library staff, individual residents of a reasonably defined geographic area in addition to walk-in patrons while on-site; (2) For schools and academic institutions: currently enrolled students, faculty and staff in addition to walk-in patrons and visiting scholars while on-site; and (3) For other types of organizations: employees, independent contractors and other temporary workers while performing duties within the scope of their employment or assignment."
Note that (1)(c): (non profits) does not offer relief from these restrictions:
"Notwithstanding the previous paragraph, if you represent a public library, educational institution, governmental agency or non-profit institution allowing public access to data and information, then, subject to any special restrictions of the copyright owner, you may provide public access to and retrieval of data and information through the Products by or for walk-in public users while on-site. You will limit such use to the customary services provided to patrons and you will not re-distribute the materials retrieved from the Products or provide access to the Products to other libraries or third parties either directly or indirectly, unless specifically authorized by ProQuest."
We would need a specific agreement with ProQuest to do what we are proposing to do, and I doubt that will happen, or that it would be useful in any case, to wit:
(6) Linking. Subject to Publisher Restrictions, you may link to search results or materials contained in the Products licensed to you. The security embedded in these links is your responsibility and only on-site users and/or Authorized Users are permitted access to the Products or the materials contained therein consistent with Sections 1(b) and 1(f) of this agreement. With respect to any original materials and third party materials that may be presented in conjunction with links into the Products, you represent that you have all rights necessary to use these third party materials.
And that's just for linking. Etc.
I think we should close the issue of using ProQuest material and put our collective energies into finding other sources appropriate for our intended use, either third-party or internal. Meanwhile, I will suspend access to this material on the new website prior to the launch date.
well, ok, i'm no lawyer, but i _did_ spend nine years interpreting employee benefit plan documents and numerous sections of the related federal tax code, regulations, etc., and this stuff is trivial by comparison. I'm just trying to remain uninvolved with anything with the potential to lead to civil or criminal courts.
this issue was first raised 2007.04.09.
had the following interaction with google analytics support that caused a minor temper tantrum (mine) this morning. the original support request was the following:
It's easiest to explain the issue by recounting the series of events:
2007.07.27:
I attempted to use the technique described in "How can I make Google Analytics identify additional search engines in the Referral reports?" to track search referrals made by our website's internal search feature.
Code excerpt:
...
We do not use any of the other tracking functions. No other changes were made.
2007.07.29:
I checked the reports this evening and noticed that nearly all traffic had disappeared.
2007.07.30:
This morning I removed the code addded three days earlier.
Subsequently:
Still not showing data in the reports. There are a very few items from visitors who did not include "www." as the domain prefix, so I know that data _is_ being collected.
Apparently, whatever error was triggered exists and persists on the server side, and there's no way I can remedy it. I will shortly be creating another profile to catch future data (assuming this error is confined to the prior profiles), but I would greatly prefer to continue capturing data in the original profiles for historical comparison purposes, etc. (accumulating since March 2007). It occurs to me that some filter could be used to remove the leading "www." from all incoming hostnames in an effort to circumvent the error we are experiencing, however, I'm not certain this would work, nor is this really the right approach to the problem.
Requested actions:
(1) Highest priority: can this error be removed from the profiles in question so that data can continue to accumulate there ?
(2) Please document this potential for persistent damage in the help center article (http://www.google.com/support/googleanalytics/bin/answer.py?answer=57046&topic=11036) so that others are warned.
(3) It would really be great if:
(a) I could use this approach to tracking internal searches the way I intended;
(b) or at least, this damaging behavior could be prevented if someone attempts the same thing in the future.
Clearly, if (1) is to be of maximum value, it would need to happen very soon.
If you could please contact me at your earliest possible opportunity I would greatly appreciate it.
Thanks,
Chris
after a couple of automated "is it plugged in?" type responses, we had the following exchange:
From: "Chris"
Subject: RE: [#xxxxxxxxx] MIssing data due to additional search engine configuration attempt
Date: Wed, 1 Aug 2007 13:23:17 -0400
Unfortunately, our situation is not covered by any of the scenarios
below. Data tracking and reporting had been working just fine until the
introduction of the code changes that I indicated earlier, and then
failed to be restored once those changes were reversed.
---Chris
From: Analytics Support [mailto:analytics-support@google.com]
Sent: Thursday, August 02, 2007 04:38
To: Chris
Subject: Re: [#xxxxxxxxx] MIssing data due to additional search engine configuration attempt
Hello Chris,
Thank you for your email. I reviewed your website and I noticed that you
have a customized implementation of the tracking code. Unfortunately,
we're unable to provide support for custom implementations of Google
Analytics. For this level of support, you can contact one of our highly
qualified Google Analytics Authorized Consultants for assistance with
advanced needs. These partners deliver a number of professional services
such as installation support, training, and advanced filter and e-commerce
configurations.
For a complete list of our worldwide partners and a more detailed
description of the services they offer, please go to
http://www.google.com/analytics/support_partner_provided.html
For additional questions, please visit the Analytics Help Center at
http://www.google.com/support/googleanalytics/?utm_id=tf. You can also
find helpful tips and information by visiting the Google Analytics Help
Forum at http://groups.google.com/group/analytics-help?utm_id=tr.
Sincerely,
Aditya
Analytics Support
*************************
For the latest updates as well as some helpful tips on Google Analytics,
check out the Google Analytics blog at http://analytics.blogspot.com
*************************
From: Chris
Sent: Thursday, August 02, 2007 09:00
To: 'Analytics Support'
Subject: RE: [#xxxxxxxxx] MIssing data due to additional search engine configuration attempt
Aditya:
Would you look at the profile on your end if I reduced the usage to simply:
_uacct = "UA-xxxxxxx-1";
urchinTracker();
I understand that "custom implementation" would be out of the scope of your support. However, we are not having problems with this part of the processing. The issue is that in an attempt to implement "How can I make Google Analytics identify additional search engines in the Referral reports?" some sort of persistent damage was incurred on the profiles at your end.
Do the Google Analytics Authorized Consultants have access to the processing at Google Analytics ? That is where this issue needs to be resolved.
Thanks for your time,
Chris
we'll see where this goes from here . yeah, i'll check their forums, post a question if i can't find anything related to this, and - hey ! - i'll google around for an answer ;-) i wonder if _they_ thought of this.
...