Recherche avancée

Sur d’autres sites (7451)

• How to track Google AdWords campaigns with Matomo

  19 décembre 2017, par InnoCraft

  In 2016, Google AdWords was the most popular ad service on earth. As a result, it may be your first source for ad spending. Are you interested in knowing whether you are making a profit out of it ? Would you like to know how to track users coming from AdWords with Matomo (Piwik) efficiently ? This is what this article is about.

  

  What you need to know about Google AdWords

  By default, each ad you create in Google AdWords is not tracked. Even worse than that, every click on your ad is identified in Matomo (Piwik) as an organic result coming from Google with the following value : “Keyword not defined”.

  To make it simple, if you do not track your AdWords campaigns both your paid and organic traffic will be biased within your Matomo (Piwik) account. It will be impossible for you to measure your return on investment and it means that you are throwing your money down the drain.

  In order to avoid this, we will show you how to track Google AdWords traffic into Matomo (Piwik).

  How to track paid Google AdWords campaigns into Matomo

  If you want to analyze Google AdWords campaigns within Matomo (Piwik) properly, you need to add additional tracking parameters to the final URL of each of your ads.

  We recommend using the following tool to add the needed additional tracking parameters : https://matomo.org/docs/tracking-campaigns-url-builder/

  You will then be able to push additional data to Matomo (Piwik) such as :

  • pk_campaign : the name of your ad campaign
  • pk_kwd : the keyword associated to this campaign
  • pk_source : the source of your campaign
  • pk_medium : the type of source, in our case either cpc, cpm, cpa
  • pk_content : the content of your ad

  If your campaign URL looks like this : https://your-website.com/, your campaign URL will then look like this after adding the campaign parameters :

  https://your-website.com/?pk_campaign=Name-Of-Your-Campaign&pk_kwd=Your-Keyword&pk_source=google&pk_medium=cpc&pk_content=My-Ad-Headline

  As each ad URL can be fired by different keywords and can correspond to different campaigns or headlines, you will need to customize the campaign parameters for each URL.

  Customizing all of your URLs individually would take you a lot of time under circumstances. That’s why you should know, that each URL parameter can be filled automatically in AdWords with a feature called “Tracking template”.

  Simplifying the campaign URL parameters with tracking templates

  You can define tracking templates either at the account, campaign or ad group level. For example, by using a tracking template at the account level, all your campaigns will have the same landing page with the URL parameters you defined in the tracking template. By defining it at the campaign level, it means that all your ad groups within the campaign will have the same landing page and so on and so forth. Any tracking template defined in a campaign, will overwrite a tracking template defined at the account level.

  Tracking template at the account level

  To edit the template at the account level, you need to click on “Settings”, then click on the “Account” settings tab and define your tracking template pattern. For example :

  https://your-website.com/?url={lpurl}&pk_campaign=AdWords&pk_kwd=Your-Keyword&pk_source=google&pk_medium=cpc&pk_content=My-Ad-Headline

  

  This will apply to all your URLs within your account. So it is only useful if your website domain is the same across all your ads. The URL parameter is compulsory here.

  It can be limiting to have a static value for “pk_campaign” and “pk_kwd” so Google allows you to use dynamic insertion, such as follows :

  https://your-landing-page.com/?url={lpurl}&pk_campaign={campaignid}&pk_kwd={keyword}&pk_source=google&pk_medium=cpc&pk_content={creative}

  The “keyword” means that the data is automatically replaced with the keyword which fired the ad within your account.

  Visit the following page if you want to know more about the different dynamic tags that AdWords supports : https://support.google.com/adwords/answer/6305348#urlinsertion

  Tracking template at the campaign level

  If you wish to define a tracking template at the campaign level, you will find this option within the “Campaign” settings under the campaign URL options :

  

  Tracking template at the Ad Group level

  You can also set it at the Ad Group level within the “Ad Group” settings :

  

  As Google mentions : “If you set up URL options at the campaign level, ad group level, or ad level, those settings will override the account-level options“.

  Now that your URLs are properly configured, you will be able to analyze AdWords traffic performances within Matomo (Piwik) once a click is coming from those sources.

  

  Did you like this article ? If yes, do not hesitate to share it or give us your feedback about the topic you would like us to write about.

• The neutering of Google Code-In 2011

  23 octobre 2011, par Dark Shikari — development, GCI, google, x264

  Posting this from the Google Summer of Code Mentor Summit, at a session about Google Code-In !

  Google Code-In is the most innovative open-source program I’ve ever seen. It provided a way for students who had never done open source — or never even done programming — to get involved in open source work. It made it easy for people who weren’t sure of their ability, who didn’t know whether they could do open source, to get involved and realize that yes, they too could do amazing work — whether code useful to millions of people, documentation to make the code useful, translations to make it accessible, and more. Hundreds of students had a great experience, learned new things, and many stayed around in open source projects afterwards because they enjoyed it so much !

  x264 benefitted greatly from Google Code-In. Most of the high bit depth assembly code was written through GCI — literally man-weeks of work by an professional developer, done by high-schoolers who had never written assembly before ! Furthermore, we got loads of bugs fixed in ffmpeg/libav, a regression test tool, and more. And best of all, we gained a new developer : Daniel Kang, who is now a student at MIT, an x264 and libav developer, and has gotten paid work applying the skills he learned in Google Code-In !

  Some students in GCI complained about the system being “unfair”. Task difficulties were inconsistent and there were many ways to game the system to get lots of points. Some people complained about Daniel — he was completing a staggering number of tasks, so they must be too easy. Yet many of the other students considered these tasks too hard. I mean, I’m asking high school students to write hundreds of lines of complicated assembly code in one of the world’s most complicated instruction sets, and optimize it to meet extremely strict code-review standards ! Of course, there may have been valid complaints about other projects : I did hear from many students talking about gaming the system and finding the easiest, most “profitable” tasks. Though, with the payout capped at $500, the only prize for gaming the system is a high rank on the points list.

  According to people at the session, in an effort to make GCI more “fair”, Google has decided to change the system. There are two big changes they’re making.

  Firstly, Google is requiring projects to submit tasks on only two dates : the start, and the halfway point. But in Google Code-In, we certainly had no idea at the start what types of tasks would be the most popular — or new ideas that came up over time. Often students would come up with ideas for tasks, which we could then add ! A waterfall-style plan-everything-in-advance model does not work for real-world coding. The halfway point addition may solve this somewhat, but this is still going to dramatically reduce the number of ideas that can be proposed as tasks.

  Secondly, Google is requiring projects to submit at least 5 tasks of each category just to apply. Quality assurance, translation, documentation, coding, outreach, training, user interface, and research. For large projects like Gnome, this is easy : they can certainly come up with 5 for each on such a large, general project. But often for a small, focused project, some of these are completely irrelevant. This rules out a huge number of smaller projects that just don’t have relevant work in all these categories. x264 may be saved here : as we work under the Videolan umbrella, we’ll likely be able to fudge enough tasks from Videolan to cover the gaps. But for hundreds of other organizations, they are going to be out of luck. It would make more sense to require, say, 5 out of 8 of the categories, to allow some flexibility, while still encouraging interesting non-coding tasks.

  For example, what’s “user interface” for a software library with a stable API, say, a libc ? Can you make 5 tasks out of it that are actually useful ?

  If x264 applied on its own, could you come up with 5 real, meaningful tasks in each category for it ? It might be possible, but it’d require a lot of stretching.

  How many smaller or more-focused projects do you think are going to give up and not apply because of this ?

  Is GCI supposed to be something for everyone, or just or Gnome, KDE, and other megaprojects ?

• How to (properly) use the ExtendRtspStream command in Google's Nest Device Access API ?

  19 juillet 2021, par 6twenty

  Using Google's Nest Device Access API, I can generate an RTSP camera stream using the GenerateRtspStream command and subsequently stop the stream using the StopRtspStream command. Makes sense, however these streams are only alive for 5 minutes by default - so the API also features another command : ExtendRtspStream.

  


  On the face of it, this sounds like it should "extend" the stream you had originally created, however these RTSP stream urls include an auth query parameter and extending a stream simply issues a new token to use for this, which means that the url for the stream changes every time it gets extended. So in reality the stream isn't getting extended at all as the url you use to access the stream still gets invalidated, and you have to restart it with a new url to continue watching the stream. So what's the point ? You may as well just call the GenerateRtspStream command and switch over to that one once the first expires. Is there some way to seamlessly change the RTSP url mid-stream that I'm not aware of using FFMPEG, perhaps ? Or to have a proxy server that broadcasts a static RTSP url and seamlessly switches the actual url each time it gets extended ?

  


  ---

  


  Rant starts here : I'm really hoping that this behaviour is actually a bug or oversight in the design of the API, and that ExtendRtspStream is supposed to keep the same url alive for as long as needed, because it's awfully pointless to have an RTSP stream that only stays alive for a max of 5 minutes. Heck, it'd be more useful to have an API that just returns the latest single-image snapshot from the camera every 10 seconds or so - but alas, there's no API for that either.