Installed, But What Next
Michael McFarland
tests in the System Log, and although it is showing me that they ran
successfully, I can't see any actual data. I am completely new to
developing in Salesforce, and so I'm looking for some advice on how to
use this Toolkit properly.
The basic premise of what I want to do is create a Dashboard that
displays a report of basic Analytics data for the clients website:
number of unique visitors, number of page views, number of page views
per visitor, number of visits per visitor.
All of this data should be available according to the documentation,
but without seeing the result from within Salesforce, I'm struggling
with what to do next.
Can I create a report that uses the custom objects from this Toolkit
directly, allowing the users to enter a data range and populate this
data? Or do I need to write additional classes that interface with the
Toolkit and then write reports against my custom classes. I'm not sure
where to focus my research efforts.
This seems like a basic premise of what folks would do with this
Toolkit and so, I will write up my experience to help others but I
need to know where to begin myself.
Please, any advice at all would be greatly appreciated.
Matthew Botos
Michael McFarland
previous version of code and the addition of a schedulable class that
called a slightly modified ImportGoogleAnalytics class. However, when
I went to migrate to production I noticed your new changes had come
out the day after I posted. I've tried to utilize the newer version,
but it is a bit limiting in the data it currently pulls. I started to
expand it to meet our needs, but there are several dependency issues.
I am curious about a couple of things, the new code seems to disregard
the ImportGoogleAnalytics class completely, in favor of a new
GoogleAnalyticsImporter class, are you planning to remove the former
from the release.
Also, I was thinking that the most flexible route for the settings
class would be to simply mimic the settings of the Google Data Feed
Query Explorer fully, rather than the limited set currently employed.
I think this would give prospective users the maximum ability to pull
any and all data required for their organizations.
http://code.google.com/apis/analytics/docs/gdata/gdataExplorer.html
I am curious about the use of the additional boolean values for 30
days. Wouldn't it make more sense to check the data for records within
the last thirty days and then set this value dynamically rather than
having a fixed boolean in settings to do this? Most folks are likely
running this as a Schedulable job as you have planned for, and so
would likely not notice the slight overhead to make this check for
each data point before proceeding.
Finally, I was thinking that the original code and indeed this new
version does not protect against duplicate metric entries. Being new
to Salesforce, I was wondering if it was possible to create complex
table keys for object records, such that the date and metric name
could combine to form a unique key that would either 1) prevent
duplicate entries to be entered or 2) overwrite old entries with
updated data if the key matched. Otherwise, when pulling reports of
the metrics you could have skewed results.
Thoughts?
On Sep 8, 3:26 pm, Matthew Botos <matthew.bo...@gmail.com> wrote:
> You highlight an important gap in the current install experience, Michael: no immediate visible results!
>
> Fortunately, we just ran a CloudSpokes challenge to do just what you suggested: provide a friendly out-of-the-box experience than provides some immediate results without any code:http://www.cloudspokes.com/challenge_detail.html?contestID=269
>
Matthew Botos
The short answer is that this is an open source project with code form multiple authors, so there's certainly room for improvement and optimization. The out-of-the box import is intended to just be simple jump start for the inevitable customization. I hope the community will take advantage of GitHub to file issues and submit pull requests with code changes & additions.
Longer answers:
Shashidhar Gurumurthy wrote the scheduled import and associated settings, so I'll let him explain his design.
The Site Metric object is fairly flexible; a nice addition would be to populate the Metric field picklist with all the valid values for Google-definied metrics. I'd be hesitant to store something along the lines of a Google Query Explorer entry, since the complex filters and other fields would be difficult to validate. For incremental imports, the dates would also be in flux.
Salesforce does support complex unique keys based on multiple fields, though it requires some effort. It would also be complicated by the fact that for any given metric and date, you might have multiple records for different filters or segments. The approach I've taken on projects where we update existing metrics is to query for existing data, add any new records, and then upsert the resulting list.
Matthew