I would like to see in analytics specific Facebook posts that are bringing traffic to the site. The 'Referrals' doesn't provide this info, but only shows how much traffic came from Facebook.com and m.facebook.com.
You can do this with the help of UTM Parameters.
What Makes Up a UTM Link?
Here’s my link for a test post
www.yourwebsite.com?utm_source=facebook&utm_medium=social&utm_campaign=post_name&utm_content=post_content
Now let’s break this link down, to understand what each metric means, and what it corresponds to in Google Analytics.
First, there is the “utm_source” value, which translates to the “source” dimension in Google Analytics. This is where traffic is coming from. You can name it whatever you want. In this example, my source is “facebook”
Equally as important is the medium, specifically “utm_medium,” which tells me what type of traffic this is. As this is from social media, I have named it social.
Easily the most important part of the link — “utm_campaign” — is the name of what you’re tracking, for example, “Summer Promotion.” Think of this as another way to roll up all the different posts and sources to see higher-level insights.
The next two metrics — “utm_term” and “utm_content” — are both optional and interchangeable. It’s about personal preference and how granular you want to get with your analysis.
If you don't want to build the URLs manually, you can use URL Builder from google.
Make sure you paste the full URL in the URL builder so that it populates the correct URL. Also make sure that you paste the whole URL created by URL builder with all UTM parameters on Facebook.
Hope this helps.
Related
I'm using the "github page" to create my personal page, but I'm going to need a hosting service because it will require some queries in the database. How can I use my GitHub Page url as a domain?
GitHub pages is not really designed for this kind of function. It's there to be a static page, where all content on the page is 'hardcoded' (meaning no dynamically generated data). What you're asking falls along the lines of a web application.
But if you're looking to be a maverick, there might be some options out there for you.
I personally haven't done something like this, but found a couple DB services you might want to check out.
Firebase by Google
RdbHost
The above recommendations may be useful if you're expecting data entry from visitors to your page. But if your data is static as well...you might be better off using s JSON file or some alternative where the data can live right in your repo.
Background:
I have a single page application that pulls data from a REST API. The API is designed such that the only URL necessary is the API root, ie https://example.com/api which provides URLs for other resources so that the client doesn't need to have any knowledge of how they are constructed.
API Design
The API has three main classes of data:
Module: Top level container
Category: A sub-container in a specific module
Resource: An item in a category
SPA Design
The app consuming the API has views for listing modules, viewing a particular module's details, and viewing a particular resource. The way the app works is it keeps all loaded data in a store. This store is persistent until the page is closed/refreshed.
The Problem:
My question is, if the user has navigated to a resource's detail view (example.com/resources/1/) and then they refresh the page, how do I load that particular resource without knowing its URL for the API?
Potential Solutions:
Hardcode URLs
Hardcoding the URLs would be fairly straightforward since I control both the API and the client, but I would really prefer to stick to a self describing API where the client doesn't need to know about the URLs.
Recursive Fetch
I could fetch the data recursively. For example, if the user requests a Resource with a particular ID, I could perform the following steps.
Fetch all the modules.
For each module, fetch its categories
Find the category that contains the requested resource and fetch the requested resource's details.
My concern with this is that I would be making a lot of unnecessary requests. If we have 100 modules but the user is only ever going to view 1 of them, we still make 100 requests to get the categories in each module.
Descriptive URLs
If I nested URLs like example.com/modules/123/categories/456/resources/789/, then I could do 3 simple lookups since I could avoid searching through the received data. The issue with this approach is that the URLs quickly become unwieldy, especially if I also wanted to include a slug for each resource. However, since this approach allows me to avoid hardcoding URLs and avoid making unnecessary network requests, it is currently my preferred option.
Notes:
I control both the client application and the API, so I can make changes in either place.
I am open to redesigning the API if necessary
Any ideas for how to address this issue would by greatly appreciated.
Expanding on my comment in an answer.
I think this is a very common problem and one I've struggled with myself. I don't think Nicholas Shanks's answer truly solves this.
This section in particular I take some issues with:
The user reloading example.com/resources/1/ is simply re-affirming the current application state, and the client does not need to do any API traversal to get back here.
Your client application should know the current URL, but that URL is saved on the client machine (in RAM, or disk cache, or a history file, etc.)
The implication I take from this, is that urls on your application are only valid for the life-time of the history file or disk cache, and cannot be shared with other users.
If that is good enough for your use-case, then this is probably the simplest, but I feel that there's a lot of cases where this is not true. The most obvious one indeed being the ability to share urls from the frontend-application.
To solve this, I would sum the issue up as:
You need to be able to statelessly map a url from a frontend to an API
The simplest, but incorrect way might simply be to map a API url such as:
http://api.example.org/resources/1
Directly to url such as:
http://frontend.example.org/resources/1
The issue I have with this, is that there's an implication that /resource/1 is taken from the frontend url and just added on to the api url. This is not something we're supposed to do, because it means we can't really evolve this api. If the server decides to link to a different server for example, the urls break.
Another option is that you generate uris such as:
http://frontend.example.org/http://api.example.org/resources/1
http://frontend.example.org/?uri=http://api.example.org/resources/1
I personally don't think this is too crazy. It does mean that the frontend needs to be able to load that uri and figure out what 'view' to load for the backend uri.
A third possibility is that you add another api that can:
Generate short strings that the frontend can use as unique ids (http://frontend.example.org/[short-string])
This api would return some document to the frontend that informs what view to load and what the (last known) API uri was.
None of these ideas sound super great to me. I want a better solution to this problem, but these are things I came up with as I was contemplating this.
Super curious if there's better ideas out there!
The current URL that the user is viewing, and the steps it took to get to the current place, are both application state (in the HATEOAS sense).
The user reloading example.com/resources/1/ is simply re-affirming the current application state, and the client does not need to do any API traversal to get back here.
Your client application should know the current URL, but that URL is saved on the client machine (in RAM, or disk cache, or a history file, etc.)
The starting point of the API is (well, can be) compiled-in to your client. Commpiled-in URLs are what couple the client to the server, not URLs that the user has visited during use of the client, including the current URL.
Your question, "For example, if the user requests a Resource with a particular ID", indicates that you have not grasped the decoupling that HATEOAS provides.
The user NEVER asks for a resource with such-and-such an ID. The user can click a link to get a query form, and then the server provides a form that generates requests to /collection/{id}. (In HTML, this is only possible for query strings, not path components, but other hypermedia formats don't have this limitation).
When the user submits the form with the ID number in the field, the client can build the request URL from the data supplied by the server+user.
According to Roy Fielding's Hypermedia As The Engine of Application State (HATEOAS), each resource should be accompagnied with a list of actions (or links) that can be done on that resource.
If the actions are included in the entity (as apposed to using the links attribute of Json-Schema), how do I tell the user-agent that a specific option is not available to the authenticated user?
The backend could do the filtering, but then the same resource URL could have different representations depending on the authenticated user. And this does not seem REST-friendly or caching friendly.
The other option is to leave all links, and let the user-agent receive a 403 Forbidden when the action is not available to the authenticated user. This can be annoying to the user.
How to inform the user-agent on the available actions when those can change depending on the authenticated user, while remaining REST-friendly?
You are correct. Creating representations that vary based on user permission is not particularly cache friendly. Is it possible to classify permission variants into just a few categories? e.g. resource-low-security, resource-medium-security resource-high-security
Sometimes this approach is possible, sometimes it is not. The other aspect to consider is whether caching is critical for this particular resource. Maybe it is now?
Also, it is not necessary to wait until the user clicks on a link to find out if the user has the permissions to follow it. The client could perform an OPTIONS request on links in the background to discover which links are available and dynamically disable the links that are not accessible.
There is no single answer to this problem. Different solutions will work in different cases depending on the requirements.
Consider that a REST API is a website for a robot to browse.
Do websites return HTML resources (pages) containing links that you're not permitted to see?
Whether it does or not, it doesn't change how "hypermediary" the website is.
but then the same resource URL could have different representations depending on the authenticated user
Consider the same about the homepage of a website. A resource is conceptual, the home page is the concept, what it looks like changes.
How does the web deal with the caching of pages for logged-in and logged-out views?
The first way is to bar caching of those resources; not everything must be cachable, the constraint is simply that resources can be labeled accordingly.
The second is using control semantics, or headers if you're using HTTP for your REST API.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary
I'm investigating usage of CPA ad types in our application and was reading about pixels for tracking conversions. It states that there are JS/HTML pixels available, but I'm wondering if there is a pixel that could be triggered on server side, (i.e. using file_open from our script). This would be a huge benefit for my app, since it would enable me to lower discrepancy and also allow more flexibility.
Does anyone have an idea?
No, there is no ability to record conversion using a server-to-server method at the moment.
Now you have options for behavior like this. Note: You cannot fire a "piexl" from the server, because pixels are specific to web pages.
Facebook created the Offline Conversions api to allow you to upload conversions that happen outside a website, like users purchasing something in a brick and mortar, or conversions that don't count until you have verified the information yourself (i.e. you must have a human review a user's sign up)
Now the right way to do it is using the Conversions API:
The Conversions API allows advertisers to send web events from their servers directly to Facebook. Server events are linked to a pixel and are processed like browser pixel events.
So it's exactly what you need.
(It's previously called Facebook Server-Side API, by the way.)
All,
I need to create an app for work that signs into our website using SSL and returns our member information.
I have figured out how to log in but am not sure how to find the id tags that I want to bring into my app and store to be show in a table view.
I know how to do these three things.
Put in username and password,
authenticate against website,
create session cookie.
Not sure how to do these things.
Get information about member, ie, how long a member , sustaining member, ect from the website knowing the tags for these fields on the site.
Store the data (core data?) or flat file. Shouldn't be that much information.
Format and present data in table view.
Lots of information here about getting files or whole websites but not so much about picking information off websites for concise viewing.
Thanks.
If your company's site is designed to provide this information through a web service, then it should be as simple as constructing your request URLs appropriately. If it has not been designed to interact with anything but humans, then you're probably going to have to do a great deal of work parsing HTML which no one can really help you with unless said site is publicly accessible.
Web Services should work fine with our website.