Embedding Youtube videos on your website can be very easy, but the typical ways of doing it can slow down your page load time. If you want to ensure the best user experience, then you can improve your page speed performance by lazy loading Youtube videos with a facade. Here’s how to do it using lite-youtube.
1. Add the Script
First, add the following script to your web page footer:
The HTML link inside the lite-youtube element is a fallback, that will only be displayed when someone’s browser can’t run the lite-youtube script.
3. Customize for Each Video
Make sure to update the following attributes for each video:
videoid: The unique identifier of the YouTube video, a series of random letters & numbers in the embed link
videotitle: The title of the video
width: The width of the video player
height: The height of the video player
href: The full YouTube URL of the video
Fallback text: Update the text inside the <a> tag
4. Determine Video Size
To determine the correct width and height for each video:
Open your browser’s developer tools
Inspect the current YouTube embed
Look for the computed style to find the exact dimensions
That’s it! Now when your page loads, the videos will initially be rendered as images. The embedded Youtube player won’t load until you click the image. This method eliminates a lot of javascript execution and load time, improving your page speed performance and SEO.
I recently worked with a client at the beginning of their SEO strategy. This case study outlines our analysis and recommendations to improve their search visibility using programmatic SEO techniques. I wrote up my general recommendations for anyone interested in Programmatic SEO here.
Initial Assessment
The client had a significant amount of unique content, but it was not being indexed properly due to a number of technical issues. Some of the problems we identified:
Most of the content lived on a subdomain, not the primary domain – not a huge issue, if everything else is good
Neither the subdomain nor the primary domain had a robots.txt or sitemap.xml
Page content was largely being loaded through React Javascript calls, instead of being pre-rendered on the page, leading to various page speed issues
No directory index pages
No inter-linking across pages
I showed them the Zapier app directory, which is an excellent example of how to generate many thousands of pages with unique content, as well as directory index pages for browsing the content. One interesting question they had was “are more pages better?”. The answer is: yes, more pages are better, but only if each page has mostly unique content. All the pages can follow the same template structure, but if you diff across pages, there should be plenty of significant content differences.
Recommendations
Based on our findings, we figured out a set of prioritized recommendations, starting with the easiest wins:
Implement robots.txt and sitemap.xml: This is the first step to guide search engines on how to crawl and index the site. Both the top-level domain (TLD) and subdomains need these files. A simple robots.txt that allows all user agents is fine to start with, as long as there’s something. And you can also link to the sitemap.xml in the robots.txt.
Switch to 301 Redirects: We advised the client to use 301 redirects instead of 302 to ensure that link equity is passed correctly, which is crucial for SEO.
Optimize On-Page Elements: Titles, meta descriptions, and H1 tags should be optimized to highlight the unique keywords on each page. Each page should have a single H1 tag that closely matches the page title.
Use SEO Tools: Setup Google Search Console, Bing Webmaster Tools, and an SEO tool like ahrefs to see how the content is being indexed and how well it is performing. Most people don’t realize that Bing is the backend search index for most alternative search engines like duckduckgo.com, so it’s important to factor them in to improve your reach.
Generate Directory Index Pages: Create index pages from top-level category items to enhance navigation and SEO.
Inter-Linking Across Content: Create links between related pages using categories, or any other content relationships.
Static HTML Generation: Instead of loading content through React in real-time, generating static HTML pages can greatly improve load times and indexing quality.
Load Balancer Implementation: By putting a load balancer in front of the main domain, they can then point a specific path to the subdomain, thus eliminating the need for a visibly separate subdomain and 301 redirects.
Mobile Optimization: Ensuring the site is optimized for mobile rendering is crucial for improving search ranking. All search engines now prioritize mobile pages and mobile rendering.
Conclusion
Programmatic SEO can provide substantial improvements in search visibility and user experience when implemented correctly. Generating thousands of pages programmatically is a great way to scale your content and visibility. But it’s crucial to get the technical implementation correct, otherwise the search engines will not properly index the content, and your pages just won’t show up in search results.
I’m working on an Etsy app for some client work (an Etsy listing scheduler) and just getting started is quite a process. So I’m documenting it here for anyone else that may be interested in creating an app for Etsy.
Step 1: Have a Real Etsy Account
To begin, you’ll need a real Etsy account. If you don’t have one already, sign up for an account on the Etsy website.
Step 2: Create a Test Etsy Store
Next, create a test Etsy store that is real enough for testing purposes. You need to create a real listing, even if it’s a digital item that is some throw-away photo. You also need to connect a real bank account to receive payouts. This Etsy store will be your test environment for developing your app.
Step 3: Set Store to Developer Mode
To ensure that your listings are not visible in Etsy’s search, set your store to Developer mode. Only do this if you’re working through your own personal account. Do not do this for a real Etsy shop.
Step 4: Create a Webpage
Create a webpage for your Etsy app. This will serve as the main interface for users to interact with your app. But for now, it’s really for the Etsy app approval team, so they can learn about the purpose of your app.
Step 5: Review Etsy’s Terms and Conditions
Before proceeding further, carefully review Etsy’s terms and conditions. A specific restrictions they have is that you cannot use the term “Etsy” in the name of your app or the title/heading of your website. You should also include the following text on your website: The term ‘Etsy’ is a trademark of Etsy, Inc. This application uses the Etsy API but is not endorsed or certified by Etsy, Inc.
Reach out to the Etsy Developer Support team by emailing developers@etsy.com. This shouldn’t be necessary since you registered in the previous step, but if you actually want to get a response and your app approved, you need to email them. Someone will review your website and registration to ensure it complies with their terms before approving your app.
Step 8: Start with Personal Token
Initially you will only get a personal API token, which means you can only interact with your own store through the API. This will allow you to test and iterate on your app’s functionality. You’ll need to actually create an initial version of your app before requesting commercial access.
Step 9: Provisional Users
As you progress with your app development, you may want to test your app on other stores. You can add provisional users with a special API.
Step 10: Create Material for Etsy Review
Prepare all the necessary materials, such as documentation and screenshots, for Etsy’s commercial API review process. This might include OAuth permissions required, and API calls that your app makes. These materials will help Etsy understand and evaluate your app.
Step 11: Request Commercial Access
Once your app is ready for wider usage, request commercial access from Etsy. This will allow anyone to authenticate and use your app via OAuth, once you’re approved.
Do you use a sentiment analysis API or tool? Or have you considered using one but couldn’t find one that fit your needs?
If the answer to either of those questions is yes, then please fill out this Sentiment Analysis Survey. I’d like to learn more and hear directly from users and customers of sentiment analysis tools. Thanks for your time.
When you’re analyzing payments to determine if they are fraudulent, what should you look for? Stripe Radar is great at blocking the more obvious fraudulent payments, and allowing the payments that are clearly not fraud, but what about the payments that are in between? There are a number of less obvious factors you can look at to determine whether a payment is fraud.
How to Decide if a Payment Under Review is Fraudulent
Here are 5 lesser known factors we’ve identified when working with clients of Streamhacker Technologies. We’ll describe each of these in more detail below
History of adding & removing cards
Specific fraud insights
Fast plan upgrades
Lack of product usage
Multiple IPs and payment attempts
While this article uses examples from Stripe, these factors can apply to almost any payment platform.
History of adding & removing cards
When a customer uses multiples cards to make payments over a relatively short period of time, that’s a big warning sign of card testing. When combined with fast plan upgrades, multiple IPs, and lack of product usage, then you can be confident it’s fraud.
Much of the time, Stripe will show this behavior in the Related Payments section of a charge. You can see an example here.
However, sometimes you need to go into the customer profile to get the full picture. In the Recent Activity section, you can see if the customer added a new card. Here’s an example of what it looks like when someone changes cards within ~1 day of signing up.
On its own, this is suspect but not necessarily fraud. However, if there’s more than 2 cards, that’s quite suspect. Also very suspect if the cards come from multiple countries. If you click on Show details for any of the cards, you can see the countries.
Above you can see 2 different cards from 2 different countries. And in this case, the customer’s IP address was in a third country. Very suspicious behavior.
Specific Fraud Insights
On a Stripe charge payment, there’s a Fraud Insights button that shows you various fraud factors. Three that we’ve found to be useful are shown below.
A low authorization rate and more than 0 declines associated with the customer’s email are significant fraud indicators. The name-email similarity match is a small additional indicator on top. These insights are most useful when combined with the other indicators discussed here.
Fast Plan Upgrades
A “fast plan upgrade” is when someone subscribes to the lowest plan of your service, then upgrades to one of your highest plans within a few minutes. This may be another form of card testing. Maybe your lowest plan is $10 and your highest plan is $100 – those are very different purchase amounts, and a card tester may want to find out if the card that works at a low amount can also be used for larger purchases. If the first upgrade attempt fails, and they switch cards to try again, fraud risk looks a lot more likely. These related payments show an example of this exact behavior.
Here’s what happened:
Attempted to purchase low level plan at $10, but that failed
Switched cards and tried again, Stripe risk score was still 0
One minute later, successfully upgraded to a higher plan, and got a risk score of 47, which Stripe still considers “normal”
1 day later, tried to upgrade again to an even higher plan, but that failed with a higher risk score
Note: 2 payments are showing as Refunded because they were successful until being refunded as fraud.
Lack of Product Usage
If a new customer doesn’t use your product much right away, that’s ok. But if they also change cards and/or try to upgrade plans without using your product at all, that’s suspicious. In Streamlining Stripe Reviews with Webhooks and Zapier I described how we helped a client highlight product usage metrics as part of their Stripe review process. Getting some product usage metrics into your Stripe charge metadata is very useful for fraud analysis, so you can quickly look at all your risk factors in one place.
Multiple IPs and Payment Attempts
Many people use VPNs and proxy servers for very legitimate reasons. And sometimes people are traveling. Just because the credit card country doesn’t match the IP country, or there’s a low authorization rate for an IP address, that doesn’t necessarily mean a payment is fraud. But when the IP address of a customer changes over a short period of time, and they make multiple payment attempts from multiple IP addresses, that’s unusual. Stripe’s Related Payments section helps to show this kind of behavior.
Conclusion
Deciding whether a payment is fraud can be tricky, and is not always obvious. But there are risk indicators you can look for, and when you see multiple indicators together, you can be more confident in a fraud assessment. Conversely, if you only see one of these indicators, then a payment likely isn’t fraud. Whatever your assessment is, take detailed notes. Stripe’s charge UI has a nice feature where you can leave a note for future reference – be sure to use this so you have a history of why you made a decision, and can revisit these decisions in the future, when you have more information.
Here are some helpful links from Stripe on identifying and preventing payment fraud:
If your company is handling payments through Stripe, you’re likely familiar with their Radar product, which helps protect you from payment fraud. And if you’re using Stripe Radar, then you may have experienced the issue of receiving a lot of Stripe Review emails. Handling all of these reviews can be time-consuming and difficult to manage effectively, and the Stripe review email doesn’t provide any useful information on its own. Getting one email for each review means they can pile up, and sometimes you might go through all the reviews within the Stripe dashboard, but the emails are still in your inbox demanding attention, as if the review is still open. In this case study, we’ll explore how Streamhacker Technologies helped a company tackle this problem using the Stripe API, custom webhooks, and Zapier.
The Problem: Too Many Stripe Review Emails
The billing team found themselves inundated with a high volume of individual review emails from Stripe Radar. Although these emails were meant to highlight potentially fraudulent charges, they often caused annoyance and frustration. The team observed that by the time they opened some reviews, they were already closed due to another team members action, or by automatic fraud controls that got triggered after the review email was sent. In most other cases, the information they needed to make a fraud determination was found elsewhere, in a separate system, with no direct links from Stripe. This back and forth was an inefficient use of their time and attention, and they needed a better solution.
The Solution: Webhooks and Zapier
We devised a solution that utilized Stripe’s API, custom webhooks, and Zapier to streamline the payment review process.
First, we created a custom webhook to retrieve additional customer information associated with each charge. This information helped indicate which reviews were more actionable, by including things like customer age and product usage metrics.
Send a single digest email every morning, containing all the open Stripe reviews, with specific indicators to help decide which reviews require attention
Create a mail rule to automatically close the individual Stripe review emails
The Result: Efficient Stripe Review Processing
After implementing this solution, the team noticed a significant reduction in time spent processing fraud reviews. They were able to quickly identify reviews that required action, analyze the payments and customer behavior faster, and they no longer wasted time opening reviews that had already been closed.
Conclusion
Simple custom webhooks + Zapier = more efficient business operations. In this case, we were able to help the team save significant time and attention by improving their existing payment review process, which freed them up to focus on other business problems.
If you think your team or company might benefit from a similar solution, contact Streamhacker Technologies to see what we can do for you.
