I want to include a new link block on my pages. But before I activate it I want to test if it makes sense.
So following Optimizelys Article on Pageview goals I set up a test to measure page view conversions. But obiously I am doing it wrong.
As a simplified example let's assume, all my pages have URLs of the following pattern: www.mydomain.com/page_[0-9]+.htm
(for example www.mydomain.com/page_123.htm).
And my new link will lead the user to another page of the above pattern.
The problem seems to be that Optimizely does not really count the number of pages visited, but instead counts the first visit already as a conversion (given that the URL pattern always matches).
So both my test variations turn out the same results.
What am I doing wrong here?
I found a workaround which seems to do the trick (although not being the perfect solution):
Using Javascript I append #opt (or whatever you like) to the links in question.
And the goal pattern is accordingly changed to www.mydomain.com/page_[0-9]+.htm#opt.
This way...
the first page the visitor visits will not be counted as a conversation (since #opt is missing)
all the other pages on the page won't be counted for the same reason
except the ones that are specifically targeted in my tested links.
Related
Let's say I want to search for McDonalds in a certain location using Facebook's graph API, like so. Now, since I know that Facebook won't always give me back all the results I want on the first page, or even the number of results I asked for, I follow the pagination link. This is the one I was given. Now, this second page loses the query string, and returns a bunch of results near the search location, but having nothing at all to do with McDonalds (e.g. Tufenkian Artisan Carpets Chicago). How can I tell when I have no more applicable results, if the pagination drops my original query entirely?
It looks like removing the limit parameter causes pagination to correctly have the query on future pages: see the same search without the limit parameter.
Say I have a website that has 100 products. Then this is filtered down to 5 sections containing 20 products each. If you were in one of the sections that contained 20 products (e.g. toys), what would be the optimal method to display only 5 toys per page. At the bottom of the list would be next/previous buttons to show the next/previous set of 5 toys.
A better analogy would be google search. There are millions of results but only ~10 are shown at a given time.
So right now I'm using google app engine (python) and django templates. One way I thought of to remedy this problem would be making all the query results go into a div which could then be modified through javascript to give a similar effect. However, if someone were to click their browser's back button, they wouldn't go where they originally came from.
Thanks in advance. Any help would be useful...I don't know what this technique is called so google hasn't been really useful :(
Edit: based on responses, I found my question was solved here: How to use cursor() for pagination?
Look into query cursors. Thay are made to be serialized and sent to client, to be used in creating "next" and "previous" paging requests.
NOTE: don't use offset on queries. This can be VERY expensive, as it actually fetches (and charges) all entities up to offset+limit position, but returns to application only limit results.
I'm not sure that putting all the results as hidden content in the HTML and manipulating it using JS is a very good idea if you might have a large result set (think about what happened if Google used this approach). There's also the back functionality issue that you've mentioned.
So, as for querying a wanted "results page" each time, I think the Google's GQL Reference might help you, take a look specifically at the LIMIT clause, it can help you create the paging mechanism you're looking for by supplying it with the number of items-per-page you want as "count" and the numbers of items-previously-viewed as "offset" (0 at first call).
As for displaying, I think that the Google Images / Facebook News Feed approach might also be interesting to think about (loading on scroll instead of paging), but that's a matter of your personal choice :)
Hope this helps, good luck!
EDIT: After reading Peter's answer, I found it much more efficient to use cursors for pagination, a good reference is given in his answer.
I have added facebook like buttons to each entry on my blog - although I have given each entry it's own URL by including an anchor name, clicking Like on one adds to the like count of all of them. Any advice on how to sort this?
An example of the code is:
Well my initial guess is that Facebook ignores the anchor. You could try passing a parameter, e.g.
www.example.com/myblog.html?entry=1#entry1
www.example.com/myblog.html?entry=2#entry2
Good luck
Looks like an issue was closed related to the question I'm about to ask, so I wonder if I'm going to be skating on thin ice, but here goes. I feel like even though this is kind of localized by nature, it could be a useful example for other developers dealing with the Like button.
I seem to be having issues regarding the Facebook like button. The infuriating part is that I'm pretty confident I have everything setup properly, and even though the linter says "hey, this all looks kosher!" the like button fails to get the correct content and uses cached info from a different page.
Here's the case: referlocal.com. We serve daily deals, and list them right off the homepage. There can be one of many deals listed on that homepage, so obviously Facebook is seeing just one when it goes to take a peek at the root directory. Now, on the homepage, whatever deal your viewing has a FB Like XFBML tag with href and ref attributes set. Every page that displays a deal also has OG tags pointing directly to the offer view page. Deals can also be viewed on user pages. So, on these three paths:
/
/{username}
/offers/{city}/{title-url-alias}
a like button is included as well as OG tags that point to /offers/{city}/{title-url-alias}. For about 3 weeks, the button worked like a champ. But recently, it's been performing strangely. For any deal, regardless of the 3 locations, it always uses the information cached from the previous days "/" deal. Regardless of the OG tags or origination.
Here's the wildly confusing part. The Facebook Linter is supposed to recache the information on the page, right? Well, it sort of does. It picks up on all of the appropriate information set in the OG tags, but when you click the Like button at the bottom of the page, no dice, still uses the deal FB saw on the homepage from the day before.
I know this is probably killing my argument for localization, but check this out:
http://developers.facebook.com/tools/lint/?url=http%3A%2F%2Freferlocal.com%2Foffers%2Fdallas%2Fget-20-of-authentic-italian-american-cuisine-for-only-10-at-leggios-italian-ristorante-dallas
Regardless of the fact that the linter finds all the appropriate information, the like button at the bottom still is liking a deal FB cached from the previous day.
Any ideas?
I had this problem too. The linter caches things in a very weird manner - seems like the best thing to do is either to add a query string and change it every time, or just rename the file every time you're checking.
I'm developing a blog application using Django. Currently, the URL /blog/ displays the front page of the blog (the first five posts). Visitors can then browse or "page through" the blog entries. This portion is mapped to /blog/browse/{page}/, where page, of course, is an integer that specifies which "page" of blog entries should be displayed.
It's occurred to me, though, that perhaps the "page number" should be an attribute of the querystring instead (e.g., /blog/browse/?page=2), since the content of the browse pages is not static (i.e., as soon as I add another post, /blog/browse/2/ will have different contents than it had before the post was added). This seems to be the way sites like Stack Overflow and Reddit do things. For example, when paging through questions on Stack Overflow, a "page" attribute is used; likewise, Reddit uses a "count" attribute.
Extending this thinking, I realize that I use the same template to render the contents of both /blog/ and /blog/browse/, so it might even make sense to just use a URL like /blog/?page=2 to page through the contents of the blog.
Any suggestions? Is there a "standard" way of doing this, or at least a "best practice" method to use?
For my money, the best general purpose approach to this issue is to use the django-pagination utility. It's incredibly easy to use and your URLs should have the format you desire.
I prefer to use the GET URL parameter, as in URL?pg=#. It's very common and provides a standard visual clue to users about what is going on. If, for instance, I want to bookmark one of those pages or make an external link, I know without thinking that I can drop the pg parameter to point at the "latest" front-page index. With an embedded #, this isn't as obvious... do I leave off the parameter? Do I always have to set it to 1? Is it a different base URL entirely? To me, having pagination through the GET parameter makes for a slightly more sensible URL, since there's an acceptable default if the parameter is omitted and the parameter doesn't affect the base URL.
Also, while I can't prove it, it gives me the warm fuzzy feeling that Google has a better chance at figuring out the nature of that page's content (i.e. that it is a paginated index into further data, and will potentially update frequently) versus a page # embedded inside the URL, which will be more opaque.
That said, I'd say this is 99% personal preference and I highly doubt there's any real functional difference, so go with whatever is easier for and fits in better with your current way of doing things.
EDIT: Forgot to mention that my opinion is Django specific... I have a few Django apps so I'm relatively familiar with the way they build their URLs, and I still use a "pg" GET parameter with those apps rather than embedding it in the URL directly.
It seems like there are two things going on. A static page, that won't change and can be used for permalinking, like an article, as well as a dynamic page that will update frequently. There is no reason you cannot use both. URL rewriting should allow this to work quite nicely. There's no reason to let the implementation control the interface, there is always at least one way to skin every cat.