<p>I know this is an old post, but if this plot is from <em>after</em> trimming I would suggest a different explanation: some trimming tools remove poly-A sequences from reads. If that's the case then any read ending with <code>A</code> will have that removed, this leads to a 0% <code>A</code> base content in the final base position (and a dropping %<code>A</code> in the final couple of bases).</p>

<p>This should have no effect on alignments or analysis.</p>

CC BY-SA 4.0
2020-05-20T09:22:48.993Z
2020-05-20T09:22:48.993Z
ewels
<p>I expect there was a sequencing problem during the last base, where some of the reagents were running low on the sequencer. This won't pose any real problem, RNAseq aligners like STAR will just soft-clip the last base or two if they're mismatches.</p>

<p>It's common to see a bit of bias toward the 5' or 3' ends in RNAseq, mostly due to whether poly-A selection was done or there was a bit of degradation. The primary thing to ensure is that the bias is similar across samples/groups. If that's the case then you don't have to worry that your downstream analyses are going be affected by some sort of per-group bias.</p>

CC BY-SA 3.0
2018-02-18T14:39:35.907Z
I'm using hisat2 and yes I see the bias is similar across samples. Thanks for the answer.
stack_learner
CC BY-SA 3.0
2018-02-18T14:41:27.717Z
Ah, for hisat2 you might get a bit better results if you trim off the last 1-2 bases. This is because hisat2 does global alignments (i.e., it doesn't do soft-clipping). Or at least that was the case last time I checked.
Devon Ryan
CC BY-SA 3.0
2018-02-18T14:46:55.173Z
Cool. I will consider this and will trim few bases in the 3' end. Does it need any trimming in the 5' end also?
stack_learner
CC BY-SA 3.0
2018-02-18T17:13:15.733Z
Nope, the 5’ end should be ok.
Devon Ryan
CC BY-SA 3.0
2018-02-19T09:34:42.013Z
I thought tha hisat2 had a `--local` option, but when I run `hisat2 -h | grep local`, I only get `--ma <int>         match bonus (0 for --end-to-end, 2 for --local)`. No `--local` proper. The help does not look coherent.
bli
CC BY-SA 3.0
2018-02-19T09:37:24.710Z
@bli The joys of bioinformatics package documentation...
Devon Ryan
CC BY-SA 3.0
2018-02-18T14:34:53.030Z
2018-02-18T14:34:53.030Z
Devon Ryan
<p>I'm working with rna-seq samples. I see 5' bias and also 3' bias in the per-base sequence content plot. From this <a href="https://sequencing.qcfail.com/articles/positional-sequence-bias-in-random-primed-libraries/" rel="noreferrer">link</a> I see that the bias at the start of the sequences appears to be the result of biased selection of fragments from the library. And this won't effect any downstream analysis. But In all of my samples I also see bias at the end of the sequences. What can be the problem? Samples are strand-specific sequenced with poly-A selection protocol.</p>

<p>In the Transcript coverage profile I see 5'-3' bias for all my samples is: 0.9</p>

<p>Showing the per-base sequence plot for one of the sample: For all the samples I see that 5' and 3' bias.</p>

<p>When I looked at Adapter content this is what I see:</p>

<p>No samples found with any adapter contamination > 0.1%</p>

<p><a href="https://i.sstatic.net/OlEp0.png" rel="noreferrer"><img src="https://i.sstatic.net/OlEp0.png" alt="enter image description here"></a></p>

<rna-seq><r><fastq><rna><rna-alignment>
5' and 3' bias in Rna-seq data
# 5' and 3' bias in Rna-seq data

(Asked by: username_0 on 2018-02-18)

I'm working with rna-seq samples. I see 5' bias and also 3' bias in the per-base sequence content plot. From this [link](https://sequencing.qcfail.com/articles/positional-sequence-bias-in-random-primed-libraries/) I see that the bias at the start of the sequences appears to be the result of biased selection of fragments from the library. And this won't effect any downstream analysis. But In all of my samples I also see bias at the end of the sequences. What can be the problem? Samples are strand-specific sequenced with poly-A selection protocol.

In the Transcript coverage profile I see 5'-3' bias for all my samples is: 0.9

Showing the per-base sequence plot for one of the sample: For all the samples I see that 5' and 3' bias.

When I looked at Adapter content this is what I see:

No samples found with any adapter contamination > 0.1%

[![enter image description here](https://i.sstatic.net/OlEp0.png)](https://i.sstatic.net/OlEp0.png)

**Tags:** rna-seq, r, fastq, rna, rna-alignment

---

## 2 answers

### Answer by username_2 on 2018-02-18. Score: 7 | Accepted answer

I expect there was a sequencing problem during the last base, where some of the reagents were running low on the sequencer. This won't pose any real problem, RNAseq aligners like STAR will just soft-clip the last base or two if they're mismatches.

It's common to see a bit of bias toward the 5' or 3' ends in RNAseq, mostly due to whether poly-A selection was done or there was a bit of degradation. The primary thing to ensure is that the bias is similar across samples/groups. If that's the case then you don't have to worry that your downstream analyses are going be affected by some sort of per-group bias.

> **Comments:**
> **username_0**: I'm using hisat2 and yes I see the bias is similar across samples. Thanks for the answer.  
> **username_2**: Ah, for hisat2 you might get a bit better results if you trim off the last 1-2 bases. This is because hisat2 does global alignments (i.e., it doesn't do soft-clipping). Or at least that was the case last time I checked.  
> **username_0**: Cool. I will consider this and will trim few bases in the 3' end. Does it need any trimming in the 5' end also?  
> **username_2**: Nope, the 5’ end should be ok.  
> **username_3**: I thought tha hisat2 had a `--local` option, but when I run `hisat2 -h | grep local`, I only get `--ma <int>         match bonus (0 for --end-to-end, 2 for --local)`. No `--local` proper. The help does not look coherent.  
> **username_2**: @bli The joys of bioinformatics package documentation...  

---

### Answer by username_1 on 2020-05-20. Score: 3

I know this is an old post, but if this plot is from *after* trimming I would suggest a different explanation: some trimming tools remove poly-A sequences from reads. If that's the case then any read ending with `A` will have that removed, this leads to a 0% `A` base content in the final base position (and a dropping %`A` in the final couple of bases).

This should have no effect on alignments or analysis.


---

