Recherche avancée

Sur d’autres sites (5752)

• Organic Traffic : What It Is and How to Increase It

  19 septembre 2023, par Erin — Analytics Tips

  Organic traffic can be a website’s most valuable source of visitors. But it can also be the hardest form of traffic to acquire. While paid ads can generate traffic almost instantly, you need to invest time and energy into growing traffic from search engines.

  And it all starts with understanding exactly what organic traffic is. 

  If you want to understand what organic traffic is, how to measure it and how to generate more of it, then this article is for you.

  What is organic traffic ?

  Organic traffic is the visitors your website receives from the unpaid results on search engines like Google, Bing and DuckDuckGo. 

  The higher your website ranks in the search engine results pages and the more search terms your website ranks for, the more organic traffic your site will receive. 

  Organic traffic is highly valued by marketers, partly because it has a much higher clickthrough rate than PPC ads. Research shows the top organic result has a 39.8% CTR compared to just 2.1% for paid ads.

  

  So, while you can pay to appear at the top of search engines (using a platform like Google Ads, for instance), you probably won’t receive as much traffic as you would if you were to rank organically in the same search engine.

  What other types of traffic are there ? 

  Organic traffic isn’t the only type of traffic your website can get. You can also receive traffic from the following channels :

  Direct

  People familiar with your site may visit it directly, either by entering your URL into their browser or accessing it through a bookmarked link ; both scenarios are counted as direct traffic.

  Social

  Social traffic includes visits to your website from a social media platform. For example, if someone shares a link to your website on Facebook, any user who clicks on it will be counted as social traffic. 

  Websites

  Social media isn’t the only way for someone to share a link to your website. Any time a visitor finds your website by clicking on a link on another website, it will be counted as “websites”. This is also known as referral traffic on some analytics platforms. 

  Campaign

  Campaign traffic encompasses both paid and unpaid traffic sources. Paid sources include advertising on search engines and social media (also known as PPC or pay-per-click), as well as collaborations with influencers and sponsorships. Unpaid sources, such as your organisation’s email newsletters, cross-promotions with other businesses and other similar methods, are also part of this mix. 

  In simpler terms, it’s the traffic you deliberately direct to your site, and you utilise campaign tracking URLs to measure how these efforts impact your ROI.

  A word on multi-touch attribution

  If you are interested in learning more about types of traffic to track conversions, then it’s important to understand multi-touch attribution. The truth is most customers won’t just use a single traffic channel to find your website. In reality, the modern customer journey has multiple touchpoints, and customers may first find your site through an ad and then search for more about your brand on Google before going directly to your website. 

  

  You are at risk of under or overestimating the effectiveness of a marketing channel without using multi-touch attribution tracking. With this marketing analytics model, you can accurately weigh the impact of every channel and allocate budgets accordingly. 

  What are the benefits of organic traffic ?

  Getting more organic traffic is a common marketing goal for many companies. And it’s not surprising why. There’s a lot to love about organic traffic. 

  For starters, it’s arguably the most cost-effective traffic your site can receive. You will still need to pay to create and distribute organic content (whether it’s a blog post or product page). You don’t need to pay for it to show up in a search engine. You continue to get value from organic traffic long after you’ve created the page, too. A good piece of organic content can receive high volumes of monthly visitors for years. That’s a stark difference from paid ads, where traffic stops as soon as you turn off the ad. 

  It also puts your website in front of a massive audience, with Google alone processing over 3.5 billion searches every day. There’s a good chance that if your target audience is looking for a solution to their problems, they start with Google. 

  Organic traffic is fantastic at building brand awareness. Usually, users aren’t searching for a specific brand or company. They are searching for informational keywords (“how to brew the perfect cup of coffee”) or unbranded transactional keywords (“best home workout machine”). In both cases, customers can use search engines to become aware of your brand. 

  Finally, organic traffic brings in high-quality leads at every marketing funnel stage. Because users are searching for informational and transactional keywords, your site can receive visits from buyers at every stage of the marketing funnel, giving you multiple chances to convert them and helping to increase the number of touch points you have.

  How to check your website’s organic traffic

  You don’t need to complete complex calculations to determine your site’s organic traffic. A web analytics solution like Matomo will accurately measure your site’s organic traffic. 

  In Matomo, on the left-hand sidebar, you can access organic traffic data by clicking Acquisition and then selecting All Channels.

  

  You’ll find a detailed breakdown of all traffic sources, including organic traffic, within the specified timeframe. The report is set to the current day by default, but you can view organic traffic metrics over a day, week, month, year or a date range of your choice.

  If you want to take things further, you can get a detailed view of organic visitors by creating a custom report for “Visitors from Search Engines only.” By creating a custom report with the segment “Channel Type is search”, you’ll be able to combine other metrics like average actions per visit, bounce rate, goal conversions, etc., to create a comprehensive report on your organic traffic and the behavior of these visitors.

  Matomo also lets you integrate Google, Bing and Yahoo search consoles directly into your Matomo Analytics to monitor keyword performance.

  How to increase organic traffic

  Follow these six tips if you want to increase the web traffic you get organically from search engines. 

  Create more and better content

  Here’s the reality : Most websites don’t get much traffic from Google. Only 40% of sites rank on the first page, and just 23% sit in the top three results. 

  Let’s take quality first. The best content tends to rise to the top of search engines. That’s because it gets shared more, receives more backlinks and gets more user engagement. So, if you want to appear at the top of Google results, creating mediocre content probably won’t cut it. You need to go above and beyond what is already there. 

  But you can’t just create one fantastic piece of content and expect to receive thousands of visitors. You need multiple pages targeting as many search terms as possible. The more pages search engines index, the more opportunities you have to rank. Or, to put it another way, the more shots you take, the greater your chances of scoring. 

  Use keyword research tools

  While creating great content is essential, you want to ensure that content targets the right keywords. These keywords receive a suitable amount of traffic and are easy to rank for. 

  Keyword research tools like Ahrefs of Semrush are the easiest way to find high-traffic topics to write about. Specifically, you want to aim for long-tail keywords. These are search terms that contain three or more words. Think “Nike men’s basketball shoe” rather than “basketball shoe.”

  

  As you can see, long tail keywords have a lower monthly search volume (250 vs. 1,100 using the example above) than broad terms but are much easier to rank for (14 vs. 41 Keyword Difficulty).

  

  While the above tools can help you find new topics to write about, Matomo’s Search Engine Keywords Performance plugin can help highlight topics you have already covered that could be expanded.

  

  The plugin automatically connects to APIs from all significant search engines and imports all the keywords people search for when clicking on your websites into your Matomo report. 

  If you find a cluster of keywords on the same topic that generates a lot of visitors, it may be worth creating even more content on that topic. Similarly, if there’s a topic you think you have covered but isn’t generating much traffic, you can look at revising and refreshing your existing content to try to rank higher. 

  Build high-quality backlinks

  Backlinks are arguably the most important Google ranking factor and the primary way Google assesses the authoritativeness of your site and content. Backlinks strongly and positively correlate with traffic — at least according to 67.5% of respondents in a uSERP industry survey. 

  There are plenty of ways you can create high-quality backlinks that Google loves. Strategies include :

  • Creating and promoting the best content about a given topic
  • Guest posting on high-authority websites
  • Building relationships with other websites

  Ensure you avoid building low-quality spam links at all costs — such as private blog networks (PBNs), forum and comment spam links and directory links. These links won’t help your content to rank higher, and Google may even penalise your entire site if you build them. 

  Find and fix any technical Search Engine Optimisation (SEO) issues

  Search engines like Google need to be able to quickly and accurately crawl and index your website to rank your content. Unfortunately, many sites suffer from technical issues that impede search engine bots. 

  The good news is that certain tools make these issues easy to spot. Take the Matomo SEO Web Vitals feature, for instance. This lets you track a set of core web vital metrics, including :

  • Page Speed Score
  • First Contentful Paint (FCP)
  • Final Input Delay (FID)
  • Last Contentful Paint (LCP)
  • Cumulative Layout Shift (CLS)

  Take things even further by identifying major bugs and issues with your site. Crashes and other issues that impact user experience can also hurt your SEO and organic traffic efforts — so it’s best to eliminate them as soon as they occur. 

  

  Use Matomo’s Crash Analytics feature to get precise bug location information as well as the user’s interactions that triggered, the device they were using, etc. Scheduled reporting and alerts allow you to automate this task and instantly detect bugs as soon as they occur.

  Improve your on-page SEO

  As well as fixing technical issues, you should spend time optimising specific elements of your website to improve how it ranks in search engines. 

  There are several on-page elements you should optimise :

  • Image alt tags
  • URLs
  • Headings
  • Title tags
  • Internal links

  Your goal should be to include a target keyword in each element above. For example, your URL should be something like yoursite.com/keyword.

  It’s best to err on the side of caution here. Avoid adding too many keywords to each of these elements. This is called keyword stuffing, and Google may slap your site with a penalty. 

  Track your content’s performance

  One final way to increase organic traffic is to use an analytics platform to understand what content needs improving and which pages can be removed.

  

  Use an analytics platform like Matomo to see which pages generate the most organic traffic and which lag behind. This can help you prioritise your SEO efforts while highlighting pages that add no value. These pages can be completely revamped, redirected to another page or removed if appropriate. 

  Conclusion

  Organic traffic is arguably the most valuable traffic source your site can acquire. It is essential to monitor organic traffic levels and take steps to increase your organic traffic. 

  A good analytics platform can help you do both. Matomo’s powerful, open-source web analytics solution protects your data and your users’ privacy, while providing the SEO tools you need to send your organic traffic levels soaring. 

  Start a free 21-day trial now, no credit card required.

• Revision 36871 : amélioreations de pas mal de choses

  2 avril 2010, par kent1@… — Log

  amélioreations de pas mal de choses

• VP8 : a retrospective

  13 juillet 2010, par Dark Shikari — DCT, speed, VP8

  I’ve been working the past few weeks to help finish up the ffmpeg VP8 decoder, the first community implementation of On2′s VP8 video format. Now that I’ve written a thousand or two lines of assembly code and optimized a good bit of the C code, I’d like to look back at VP8 and comment on a variety of things — both good and bad — that slipped the net the first time, along with things that have changed since the time of that blog post.

  These are less-so issues related to compression — that issue has been beaten to death, particularly in MSU’s recent comparison, where x264 beat the crap out of VP8 and the VP8 developers pulled a Pinocchio in the developer comments. But that was expected and isn’t particularly interesting, so I won’t go into that. VP8 doesn’t have to be the best in the world in order to be useful.

  When the ffmpeg VP8 decoder is complete (just a few more asm functions to go), we’ll hopefully be able to post some benchmarks comparing it to libvpx.

  1. The spec, er, I mean, bitstream guide.

  Google has reneged on their claim that a spec existed at all and renamed it a “bitstream guide”. This is probably after it was found that — not merely was it incomplete — but at least a dozen places in the spec differed wildly from what was actually in their own encoder and decoder software ! The deblocking filter, motion vector clamping, probability tables, and many more parts simply disagreed flat-out with the spec. Fortunately, Ronald Bultje, one of the main authors of the ffmpeg VP8 decoder, is rather skilled at reverse-engineering, so we were able to put together a matching implementation regardless.

  Most of the differences aren’t particularly important — they don’t have a huge effect on compression or anything — but make it vastly more difficult to implement a “working” VP8 decoder, or for that matter, decide what “working” really is. For example, Google’s decoder will, if told to “swap the ALT and GOLDEN reference frames”, overwrite both with GOLDEN, because it first sets GOLDEN = ALT, and then sets ALT = GOLDEN. Is this a bug ? Or is this how it’s supposed to work ? It’s hard to tell — there isn’t a spec to say so. Google says that whatever libvpx does is right, but I doubt they intended this.

  I expect a spec will eventually be written, but it was a bit obnoxious of Google — both to the community and to their own developers — to release so early that they didn’t even have their own documentation ready.

  2. The TM intra prediction mode.

  One thing I glossed over in the original piece was that On2 had added an extra intra prediction mode to the standard batch that H.264 came with — they replaced Planar with “TM pred”. For i4x4, which didn’t have a Planar mode, they just added it without replacing an old one, resulting in a total of 10 modes to H.264′s 9. After understanding and writing assembly code for TM pred, I have to say that it is quite a cool idea. Here’s how it works :

  1. Let us take a block of size 4×4, 8×8, or 16×16.

  2. Define the pixels bordering the top of this block (starting from the left) as T[0], T[1], T[2]…

  3. Define the pixels bordering the left of this block (starting from the top) as L[0], L[1], L[2]…

  4. Define the pixel above the top-left of the block as TL.

  5. Predict every pixel <X,Y> in the block to be equal to clip3( T[X] + L[Y] – TL, 0, 255).

  It’s effectively a generalization of gradient prediction to the block level — predict each pixel based on the gradient between its top and left pixels, and the topleft. According to the VP8 devs, it’s chosen by the encoder quite a lot of the time, which isn’t surprising ; it seems like a pretty good idea. As just one more intra pred mode, it’s not going to do magic for compression, but it’s a cool idea and elegantly simple.

  3. Performance and the deblocking filter.
  

  On2 advertised for quite some that VP8′s goal was to be significantly faster to decode than H.264. When I saw the spec, I waited for the punchline, but apparently they were serious. There’s nothing wrong with being of similar speed or a bit slower — but I was rather confused as to the fact that their design didn’t match their stated goal at all. What apparently happened is they had multiple profiles of VP8 — high and low complexity profiles. They marketed the performance of the low complexity ones while touting the quality of the high complexity ones, a tad dishonest. More importantly though, practically nobody is using the low complexity modes, so anyone writing a decoder has to be prepared to handle the high complexity ones, which are the default.

  The primary time-eater here is the deblocking filter. VP8, being an H.264 derivative, has much the same problem as H.264 does in terms of deblocking — it spends an absurd amount of time there. As I write this post, we’re about to finish some of the deblocking filter asm code, but before it’s committed, up to 70% or more of total decoding time is spent in the deblocking filter ! Like H.264, it suffers from the 4×4 transform problem : a 4×4 transform requires a total of 8 length-16 and 8 length-8 loopfilter calls per macroblock, while Theora, with only an 8×8 transform, requires half that.

  This problem is aggravated in VP8 by the fact that the deblocking filter isn’t strength-adaptive ; if even one 4×4 block in a macroblock contains coefficients, every single edge has to be deblocked. Furthermore, the deblocking filter itself is quite complicated ; the “inner edge” filter is a bit more complex than H.264′s and the “macroblock edge” filter is vastly more complicated, having two entirely different codepaths chosen on a per-pixel basis. Of course, in SIMD, this means you have to do both and mask them together at the end.

  There’s nothing wrong with a good-but-slow deblocking filter. But given the amount of deblocking one needs to do in a 4×4-transform-based format, it might have been a better choice to make the filter simpler. It’s pretty difficult to beat H.264 on compression, but it’s certainly not hard to beat it on speed — and yet it seems VP8 missed a perfectly good chance to do so. Another option would have been to pick an 8×8 transform instead of 4×4, reducing the amount of deblocking by a factor of 2.

  And yes, there’s a simple filter available in the low complexity profile, but it doesn’t help if nobody uses it.

  4. Tree-based arithmetic coding.

  Binary arithmetic coding has become the standard entropy coding method for a wide variety of compressed formats, ranging from LZMA to VP6, H.264 and VP8. It’s simple, relatively fast compared to other arithmetic coding schemes, and easy to make adaptive. The problem with this is that you have to come up with a method for converting non-binary symbols into a list of binary symbols, and then choosing what probabilities to use to code each one. Here’s an example from H.264, the sub-partition mode symbol, which is either 8×8, 8×4, 4×8, or 4×4. encode_decision( context, bit ) writes a binary decision (bit) into a numbered context (context).

  8×8 : encode_decision( 21, 0 ) ;

  8×4 : encode_decision( 21, 1 ) ; encode_decision( 22, 0 ) ;

  4×8 : encode_decision( 21, 1 ) ; encode_decision( 22, 1 ) ; encode_decision( 23, 1 ) ;

  4×4 : encode_decision( 21, 1 ) ; encode_decision( 22, 1 ) ; encode_decision( 23, 0 ) ;

  As can be seen, this is clearly like a Huffman tree. Wouldn’t it be nice if we could represent this in the form of an actual tree data structure instead of code ? On2 thought so — they designed a simple system in VP8 that allowed all binarization schemes in the entire format to be represented as simple tree data structures. This greatly reduces the complexity — not speed-wise, but implementation-wise — of the entropy coder. Personally, I quite like it.

  5. The inverse transform ordering.

  I should at some point write a post about common mistakes made in video formats that everyone keeps making. These are not issues that are patent worries or huge issues for compression — just stupid mistakes that are repeatedly made in new video formats, probably because someone just never asked the guy next to him “does this look stupid ?” before sticking it in the spec.

  One common mistake is the problem of transform ordering. Every sane 2D transform is “separable” — that is, it can be done by doing a 1D transform vertically and doing the 1D transform again horizontally (or vice versa). The original iDCT as used in JPEG, H.263, and MPEG-1/2/4 was an “idealized” iDCT — nobody had to use the exact same iDCT, theirs just had to give very close results to a reference implementation. This ended up resulting in a lot of practical problems. It was also slow ; the only way to get an accurate enough iDCT was to do all the intermediate math in 32-bit.

  Practically every modern format, accordingly, has specified an exact iDCT. This includes H.264, VC-1, RV40, Theora, VP8, and many more. Of course, with an exact iDCT comes an exact ordering — while the “real” iDCT can be done in any order, an exact iDCT usually requires an exact order. That is, it specifies horizontal and then vertical, or vertical and then horizontal.

  All of these transforms end up being implemented in SIMD. In SIMD, a vertical transform is generally the only option, so a transpose is added to the process instead of doing a horizontal transform. Accordingly, there are two ways to do it :

  1. Transpose, vertical transform, transpose, vertical transform.

  2. Vertical transform, transpose, vertical transform, transpose.

  These may seem to be equally good, but there’s one catch — if the transpose is done first, it can be completely eliminated by merging it into the coefficient decoding process. On many modern CPUs, particularly x86, transposes are very expensive, so eliminating one of the two gives a pretty significant speed benefit.

  H.264 did it way 1).

  VC-1 did it way 1).

  Theora (inherited from VP3) did it way 1).

  But no. VP8 has to do it way 2), where you can’t eliminate the transpose. Bah. It’s not a huge deal ; probably only 1-2% overall at most speed-wise, but it’s just a needless waste. What really bugs me is that VP3 got it right — why in the world did they screw it up this time around if they got it right beforehand ?

  RV40 is the other modern format I know that made this mistake.

  (NB : You can do transforms without a transpose, but it’s generally not worth it unless the intermediate needs 32-bit math, as in the case of the “real” iDCT.)

  6. Not supporting interlacing.

  THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU.

  Interlacing was the scourge of H.264. It weaseled its way into every nook and cranny of the spec, making every decoder a thousand lines longer. H.264 even included a highly complicated — and effective — dedicated interlaced coding scheme, MBAFF. The mere existence of MBAFF, despite its usefulness for broadcasters and others still stuck in the analog age with their 1080i, 576i , and 480i content, was a blight upon the video format.

  VP8 has once and for all avoided it.

  And if anyone suggests adding interlaced support to the experimental VP8 branch, find a straightjacket and padded cell for them before they cause any real damage.